From dougb at dougbarton.email Sat Nov 1 00:04:23 2014 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 31 Oct 2014 16:04:23 -0700 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 In-Reply-To: <5453FEFA.1090904@sixdemonbag.org> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <5453FEFA.1090904@sixdemonbag.org> Message-ID: <54541577.1020601@dougbarton.email> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/31/14 2:28 PM, Robert J. Hansen wrote: |> Anyway, gpg might want to use pinentry to gather the passphrase |> from the user, and it's not clear that you have the right |> environment set up for pinentry. | | One option would be to install GnuPG 1.4 on the host machine -- | headless servers are some of the few uses I can still see for it. That's true, although pinentry-curses actually does a pretty good job remotely unless the thing that you're calling GnuPG from is taking extreme control of the terminal. For instance, if you're ssh'ing into a remote system and running a simple shell script, or even doing gpg on the command line, pinentry-curses is fine. However if you're doing something more exotic (a mail client like Alpine for example) then all bets are off. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUVBV3AAoJEFzGhvEaGryE2zIIAJ1d573nr3crecng9hSwNstW usx9GMhx06Gh6ecqs8MnAtcs6F3ISl+GuYhL6kq8aDbo/Kmwn5TXdUii6J969Kgw +0647iAvZfsE0XkUSGIWisFUL5DGtaIWfLL1CNmAZbJxjeZy3nK/RBc7E3zshcAb EFoekXAew3JQ/fPmSjctry570P/cUM2KZCZKz5b+pOpcIp+osG/mL5bz0i/UbboL QcVy9zpOngYuXLwMKZBy9DRp+fmPE1SW/7Gs9MO33MW1LpUzuEW988FS1sf33DK+ Eg9UXEfUp+PqqMlsgtQ+Vmz+G/ETc6hP5qEX9FqSfegySgmoVviLt654S9KlHtk= =0ks6 -----END PGP SIGNATURE----- From samir at samirnassar.com Sat Nov 1 16:47:33 2014 From: samir at samirnassar.com (Samir Nassar) Date: Sat, 01 Nov 2014 16:47:33 +0100 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 In-Reply-To: <0218bea455a342bd8f170a4151718169@hioexcmbx04-prd.hq.netapp.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <0218bea455a342bd8f170a4151718169@hioexcmbx04-prd.hq.netapp.com> Message-ID: <2250528.6ilNiiUzy1@forge> Hello Mr. Kumar, I do not believe you intend to share your passphrase with a public audience on a public mailing list. Samir On Friday, 2014-10-31 21:35:53 SubramaniaRao, ravikumar wrote: > P.S: The Emphasis is, once you have reached Excellence, do not stop. I was > just created the Passphrase with the Famous Phrase ?Excellence is not an > Adjective but a Verb?, so that I can remember it.. -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From samir at samirnassar.com Sat Nov 1 16:46:35 2014 From: samir at samirnassar.com (Samir Nassar) Date: Sat, 01 Nov 2014 16:46:35 +0100 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 In-Reply-To: <0218bea455a342bd8f170a4151718169@hioexcmbx04-prd.hq.netapp.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <0218bea455a342bd8f170a4151718169@hioexcmbx04-prd.hq.netapp.com> Message-ID: <2568952.xCsFJriqv0@forge> Hello Mr. Kumar, If this is for a remote system you likely want pinentry to be configured with ncurses only and without GTK or Qt. Samir On Friday, 2014-10-31 21:35:53 SubramaniaRao, ravikumar wrote: > Daniel Kahn Gillmor, > > Thank you for your reply. Yes after sending the Mail to you, I installed the > Pinentry v0.8.4. But it gives the error " No package 'QtCore' found. We are > using Sun Solaris 10. > P.S: The Emphasis is, once you have reached Excellence, do not stop. I was > just created the Passphrase with the Famous Phrase ?Excellence is not an > Adjective but a Verb?, so that I can remember it.. > Cheers, > S. Ravi Kumar > > -----Original Message----- > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > Sent: Friday, October 31, 2014 2:05 PM > To: SubramaniaRao, ravikumar; gnupg-users at gnupg.org; Custodio, Gina > Subject: Re: Help needed to setup Passphrase with GNUPG 2.0.26 > > On 10/31/2014 01:31 PM, SubramaniaRao, ravikumar wrote: > > > Hello GNUPG Users, > > > > > > > > Help needed to setup Passphrase with GNUPG 2.0.26. > > > > > > > > We have installed the following. > > > > > > > > (a) libgpg-error-1.11 > > (b) libgcrypt-1.4.0 > > (c) libassuan-2.1.2 > > (d) libksba-1.3.1 > > (e) pth-2.0.7 > > (f) GNUPG 2.0.26. > > > > > > > > Then (1) % echo $PATH > > /u/ravikums/bin/bin.sun4:/u/ravikums/bin:/usr/openwin/bin/xview:/usr/openw > > in/bin:/usr/dt/bin:/netapp/bin:/netapp/gnu/bin:/usr/software/bin:/usr/soft > > ware/utils/bin:/usr/software/rats/bin:/usr/software/test/bin:/usr/local:/u > > sr/local/bin:/usr/ucb:/bin:/usr/bin:/usr/etc:/usr/games:/usr/lib/uucp:/etc > > :/usr/lib:/usr/sccs/bin:/usr/local/X11/sun4/bin:/usr/bin/X11:/r/frame/bin: > > /usr/sbin:/sbin:/opt/lotus/bin:/u/ravikums/notes:.:/usr/openwin/bin:/usr/o > > penwin/bin/xview > > > (2) echo $LD_LIBRARY_PATH > > > > /usr/openwin/lib:/usr/local/X11R5/sun4c/lib:/netapp/gnu/lib:/usr/openw > > in/lib:/opt/lotus/common/lel/r100/sunspa41:/usr/local/X11R5/sun4c/lib: > > /usr/local/lib:/usr/lib > > > > > > > > After that we are invoking the Command "gpg2 --gen-key-The Screen Shot is > > pasted below: The issue is, after entering the Passphrase it stays there > > forever. > > your screenshot suggests that you're doing all of this on some remote > machine via ssh (it looks like you're using putty on windows). You haven't > mentioned what operating system you're using, though. > Anyway, gpg might want to use pinentry to gather the passphrase from the > user, and it's not clear that you have the right environment set up for > pinentry. > whatever package manager you have, can you install pinentry-curses and try > again? > --dkg > > PS "Excellence is not an Adjective but a Verb" -- it's actually a noun :) > > -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tzornik at gmail.com Sun Nov 2 09:42:00 2014 From: tzornik at gmail.com (Cpp) Date: Sun, 2 Nov 2014 09:42:00 +0100 Subject: Is gpg-agent passphrase status query possible? In-Reply-To: <4198882.cFGGfkuuU6@inno> References: <4198882.cFGGfkuuU6@inno> Message-ID: Hello I see that command will print out the passphrase in clear text. Is this secure to use just like that? I mean whats the chance the passphrase gets siphoned by some other app during the parsing? Basically I'm only interested in whether the passphrase is present or not, not the actual passphrase itself. The exit status code of gpg-connect-agent does not seem to reflect the passphrase status. Regards! On 10/31/14, Hauke Laging wrote: > Am Do 30.10.2014, 23:14:12 schrieb Cpp: > >> Is there a way to "query" gpg-agent to >> see whether a correct passphrase has been recently entered for a >> particular secret key, and has not yet been forgotten? > > Yes and no. > > There is an easy way to find out whether a certain passphrase (make sure > to distinguish between mainkey and subkeys!) is currently known to gpg- > agent: > > : gpg-connect-agent "GET_PASSPHRASE --data --no-ask > 4F7E9F723D197D667842AE115F048E6F0E4B4494 t1 t2 t3" /bye > D fubar > OK > > But that doesn't tell you for how long gpg-agent will cache it yet. It > may be that the passphrase has just been deleted from the cache even if > you use the key immediately afterwards. > > > If you know for sure for how long the entries are cached then you may > write a small "daemon" which checks for the passphrases every few > seconds. Then it knows with reasonable precision when a passphrase was > added to the cache and can calculate when it will be dropped. > > > Hauke > -- > Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ > http://userbase.kde.org/Concepts/OpenPGP_Help_Spread > OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 > From peter at digitalbrains.com Sun Nov 2 12:38:58 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 02 Nov 2014 12:38:58 +0100 Subject: Is gpg-agent passphrase status query possible? In-Reply-To: References: <4198882.cFGGfkuuU6@inno> Message-ID: <545617D2.90709@digitalbrains.com> On 02/11/14 09:42, Cpp wrote: > I see that command will print out the passphrase in clear text. Is > this secure to use just like that? This is the same channel as where session keys are exchanged. With a session key, you can decrypt an encrypted message: very sensitive information. So the channel in itself is secure; it all depends on the application that uses it. I don't know if there are any other applications than GnuPG itself that use the agent[1], but in your scenario it would seem to be GnuPG itself and hence be secure. IIUC, your question is whether it's principally possible for Enigmail to decrypt only when you will not be prompted for the passphrase or PIN. The GET_PASSPHRASE --no-ask seems ill equipped to do that. Even apart from the raciness, Enigmail is quite far away from the agent interface. I /think/ Enigmail simply executes the gnupg binary, defaulting to v1.4.x which doesn't even necessarily use the agent! What seems to be needed is a --no-ask command line option to GnuPG 1.4.x or 2.0.x. This would, in the case of an agent, most likely translate into an agent command PKDECRYPT --no-ask (which also doesn't exist yet). So I think the answer is: without ugly hacks which also involve races, no, Enigmail cannot currently decrypt only when it would not lead to a prompt. But perhaps things will completely change with the new GnuPG v2.1.x? By the way: $ gpg-connect-agent "help pkdecrypt" /bye # PKDECRYPT # # Perform the actual decrypt operation. Input is not # sensitive to eavesdropping. OK I've looked at the source (2.0.26), and there are no options. Is this still a relic from something that was once there, or planned to be there? Why is it instead of [options] anyway? :) Surely that's a typo. HTH, Peter. [1] I'm excluding gnome-keyring-daemon on purpose, since it's not using but rather abusing. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Nov 2 12:59:30 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 02 Nov 2014 12:59:30 +0100 Subject: Broken mirrors Message-ID: <54561CA2.2010405@digitalbrains.com> It is a bit unclear to me where you should report broken mirrors or whether you should do so at all; I thought I'd best just post it here. ftp://ftp.surfnet.nl/pub/security/gnupg/ seems to only hold directories, no files. ftp://ftp.demon.nl/pub/mirrors/gnupg/ -> that directory doesn't even exist. It seems that you can ward off the seven years of bad luck by either burying the broken mirror under a tree or grinding it into very small bits. What a shame to do that to a good server, but it's still better than seven years of bad luck! Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From rex.k at icloud.com Mon Nov 3 17:52:34 2014 From: rex.k at icloud.com (Rex Kneisley) Date: Mon, 03 Nov 2014 08:52:34 -0800 Subject: Make step fails for gnupg Message-ID: <97AF2EFC-E5D7-4A9F-9EBD-3A1CD5EAA452@icloud.com> Hello team, I'm sorry to bother you with a newbie question. I have been trying to install gnupg 2.0.26 all morning. I have verified the installer with gnupg 1.4.12 which was reinstalled on my new version of Debian (7.7.0). I have installed the following libraries Libgpg-error-1.17 Libgcrypt-1.6.2 Licksa-1.3.1 Libassuan-2.1.2 However when I try to use the make command for Gnupg, (after ./configure), I always get an error message: ../../g10/gpg2: error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: no such file or directory. I have tried adding a gpg2.conf file to folder etc/ld.so.conf.d with the single line: /user/local/lib However, I continue to get the error message during "make" I may not have installed the libraries in the correct order I have tried re-installing them countless times in the correct order. Do I need to uninstall all of the libraries an re-install clean? Sincerely, Rex Kneisley Sent from my iPad From wk at gnupg.org Mon Nov 3 22:15:59 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Nov 2014 22:15:59 +0100 Subject: Make step fails for gnupg In-Reply-To: <97AF2EFC-E5D7-4A9F-9EBD-3A1CD5EAA452@icloud.com> (Rex Kneisley's message of "Mon, 03 Nov 2014 08:52:34 -0800") References: <97AF2EFC-E5D7-4A9F-9EBD-3A1CD5EAA452@icloud.com> Message-ID: <87zjc8q92o.fsf@vigenere.g10code.de> On Mon, 3 Nov 2014 17:52, rex.k at icloud.com said: > /user/local/lib /usr/local/lib should works better (in case it is not a typo). Then run "ldconfig"! If the problem persists, you should run ldd ../../g10/gpg2 from that directory to see why the runtime linker does not find libgcrypt.so.20. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nan at goodcrypto.com Tue Nov 4 14:45:22 2014 From: nan at goodcrypto.com (Nan) Date: Tue, 4 Nov 2014 13:45:22 GMT Subject: New Frontend for Network Related section Message-ID: <20141104134522QefMJciaqV@goodcrypto.com> I noticed your Frontends page and couldn't find any way to tell you about an addition to the Network Related section, except this list. After using gpg for many years, we made a server distro that provides almost transparent gpg (and tor) to a whole domain. Open source. Threat model, design, etc. are in the Technical FAQ at https://goodcrypto.com/qna/technical/. Most users need transparent crypto, so installation is by the sysadmin. No training and no clicks for users. Thanks again to Werner Koch and all the contributors for their excellent work on GPG. We need testers and auditors if you'd like a free subscription. Any thoughts you have are welcome. GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From dkg at fifthhorseman.net Tue Nov 4 19:09:20 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Nov 2014 13:09:20 -0500 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> Message-ID: <54591650.1040902@fifthhorseman.net> On 10/31/2014 06:10 PM, SubramaniaRao, ravikumar wrote: > Daniel Kahn Gillmor, > > Further I would like to give the output below when I ran ./configure [...] > Please help us to resolve the issue. I'm sorry, but i don't know enough about Solaris to make sense of the information you've provided. Perhaps someone else on the mailing list will be able to help you better. --dkg PS I agree with Samir Nassar on both points: a) if this is a system accessed remotely without a graphical UI, you really only want the curses interface for pinentry b) you should not publish your passphrase to a public mailing list. (you also shouldn't use a "famous phrase" as a passphrase, since it's more easily guessable) -- I hope you'll choose a different passphrase. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From Kanchan.Gobari at infogain.com Tue Nov 4 10:44:55 2014 From: Kanchan.Gobari at infogain.com (Kanchan Gobari) Date: Tue, 4 Nov 2014 15:14:55 +0530 Subject: Error on GPG file encryption Message-ID: <8E2F92E4FE282E48AC110E7F1A7431740634B8D9@nodmx01.igglobal.com> Hi, Urgent help required. I have create a UNIX script for encryption but while executing the script got the below error: gpg: cannot open tty `/dev/tty': No such device or address As got input from multiple sites - google; I found to add the '--no-tty' in the command line. But after adding the same in command line, I am getting the another error: gpg: Sorry, no terminal at all requested - can't get input Please help to resolve this quickly... Thanks & Regards Kanchan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravikumar.SubramaniaRao at netapp.com Tue Nov 4 19:23:41 2014 From: ravikumar.SubramaniaRao at netapp.com (SubramaniaRao, ravikumar) Date: Tue, 4 Nov 2014 18:23:41 +0000 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <54591650.1040902@fifthhorseman.net> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> Message-ID: <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> Daniel Kahn Gillmor, Thank you for your Feedback. Sorry, it was not the intention to advertise the Phrase or using a Famous Passphrase. I wanted to show after giving the Passphrase it was hanging. So I showed that in the Screen Shot. We wanted the Resolution for this. Yes we access the System Remotely and we tried to install the Pinentry. But it gave the error . Further I would like to give the output below when I ran ./configure It said," Perhaps you should add the directory containing `QtCore.pc' to the PKG_CONFIG_PATH environment variable No package 'QtCore' found no configure: creating ./config.status config.status: creating assuan/Makefile config.status: creating secmem/Makefile config.status: creating pinentry/Makefile config.status: creating curses/Makefile config.status: creating tty/Makefile config.status: creating gtk/Makefile config.status: creating gtk+-2/Makefile config.status: creating qt/Makefile config.status: creating qt4/Makefile config.status: creating w32/Makefile config.status: creating doc/Makefile config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands configure: Pinentry v0.8.4 has been configured as follows: Revision: f610ea6 (62992) Platform: sparc-sun-solaris2.10 Curses Pinentry ..: yes TTY Pinentry .....: maybe GTK+ Pinentry ....: yes GTK+-2 Pinentry ..: yes Qt Pinentry ......: no Qt4 Pinentry .....: no W32 Pinentry .....: no Fallback to Curses: yes Default Pinentry .: pinentry-gtk-2 ------------------ I tried to find the File QtCore.pc ngztruapp02-dev# find / -name QtCore.pc -print find: cycle detected for /apps/dtrusaas/.snapshot/hourly.2014-10-31_0803/home/infauser/informatica9.1/source/ODBC6.1/help/userguide/wwhdata/common/ find: cycle detected for /apps/dtrusaas/.snapshot/hourly.2014-10-31_0803/home/infauser/informatica9.1/source/ODBC6.1/help/userguide/wwhdata/js/search/pairs/ find: cannot read dir /u/custodi: Permission denied Please help us to resolve the issue. Cheers, S. Ravi Kumar -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Tuesday, November 04, 2014 10:09 AM To: SubramaniaRao, ravikumar; gnupg-users at gnupg.org; Custodio, Gina Subject: Re: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 On 10/31/2014 06:10 PM, SubramaniaRao, ravikumar wrote: > Daniel Kahn Gillmor, > > Further I would like to give the output below when I ran ./configure [...] > Please help us to resolve the issue. I'm sorry, but i don't know enough about Solaris to make sense of the information you've provided. Perhaps someone else on the mailing list will be able to help you better. --dkg PS I agree with Samir Nassar on both points: a) if this is a system accessed remotely without a graphical UI, you really only want the curses interface for pinentry b) you should not publish your passphrase to a public mailing list. (you also shouldn't use a "famous phrase" as a passphrase, since it's more easily guessable) -- I hope you'll choose a different passphrase. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Wed Nov 5 00:20:52 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 05 Nov 2014 00:20:52 +0100 Subject: Error on GPG file encryption In-Reply-To: <8E2F92E4FE282E48AC110E7F1A7431740634B8D9@nodmx01.igglobal.com> References: <8E2F92E4FE282E48AC110E7F1A7431740634B8D9@nodmx01.igglobal.com> Message-ID: <5134511.SygfxvBRNZ@inno> Am Di 04.11.2014, 15:14:55 schrieb Kanchan Gobari: > Urgent help required. Then you should have subscribed to the list before writing. Would have saved you 12 hours... > I have create a UNIX script for encryption but while executing the > script got the below error: > > gpg: cannot open tty `/dev/tty': No such device or address What is the command line in the script causing the error? What is the output of the following command? ls -l /dev/tty Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Wed Nov 5 16:15:18 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 05 Nov 2014 16:15:18 +0100 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> Message-ID: > Sorry, it was not the intention to advertise the Phrase or using a > Famous Passphrase. I wanted to show after giving the Passphrase it > was > hanging. So I showed that in the Screen Shot. We wanted the > Resolution > for this. You weren't entering a passhprase there. If it were asking for a passphrase, it wouldn't show your typing. Instead, your input was most likely simply not processed and echoed on the terminal. Try this and see what I mean: $ sleep 10 Just type anything interesting in the 10 seconds the program sleeps $ Just type anything interesting in the 10 seconds the program sleeps That last line will be the new prompt with what you just typed echoed /again/, as it is now processing your input and using it as the command line. > Yes we access the System Remotely and we tried to install the > Pinentry. But it gave the error . Are you sure there is an error? I interpreted it as that the Qt pinentry was simply not built, but the others, and the wanted curses pinentry was. Were there any binaries generated by the build? > CURSES PINENTRY ..: YES > TTY PINENTRY .....: MAYBE > GTK+ PINENTRY ....: YES > GTK+-2 PINENTRY ..: YES > QT PINENTRY ......: NO > QT4 PINENTRY .....: NO > W32 PINENTRY .....: NO > > FALLBACK TO CURSES: YES > > DEFAULT PINENTRY .: PINENTRY-GTK-2 See? If it's not going to build the Qt version, why would it need any Qt headers? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From rjh at sixdemonbag.org Wed Nov 5 16:56:24 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 05 Nov 2014 10:56:24 -0500 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> Message-ID: <545A48A8.4040509@sixdemonbag.org> > See? If it's not going to build the Qt version, why would it need any > Qt headers? Not to harp, but it bears repeating: use GnuPG 1.4 and this entire problem goes away. Given all the emails that have gone back and forth on this subject, I think it's probably time to make the switch to 1.4. :) From peter at digitalbrains.com Wed Nov 5 17:16:13 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 05 Nov 2014 17:16:13 +0100 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <545A48A8.4040509@sixdemonbag.org> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <545A48A8.4040509@sixdemonbag.org> Message-ID: <5296910afc73ab5121aa1e8bc0e59cd7@butters.digitalbrains.com> On 2014-11-05 16:56, Robert J. Hansen wrote: > Not to harp, but it bears repeating: use GnuPG 1.4 and this entire > problem goes away. Given all the emails that have gone back and > forth > on this subject, I think it's probably time to make the switch to > 1.4. :) Right, yes, I agree. I focussed just on the latest question and lost the context. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Nov 5 21:11:26 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 05 Nov 2014 21:11:26 +0100 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> Message-ID: <545A846E.90206@digitalbrains.com> On 05/11/14 20:52, SubramaniaRao, ravikumar wrote: > Thank for your Input. Please help me where I will get the tar File for > Qt pinentry, so that I can install it. If QT Pinetry is not required, Is it perhaps possible that you only notice the contributions to this thread that are explicitly mailed to you, as opposed to the ones that are only addressed to the mailing list? Because there are several contributions on the mailing list that you don't seem to notice. I'm talking specifically about the suggestion by Robert J. Hansen that it seems that you might be much better served by GnuPG 1.4. I really suggest you look at that, perhaps returning to the mailing list if there are any further issues. As an aside, a pinentry for Qt is of no use when you use PuTTY to connect to the server, unless you have a very specific setup. I think you would need an X server running on your Windows machine to get that working. I used to have that a long, long time ago. It was quite a hassle to set up and frequently needed a good kicking to keep chugging along ;). It was not a well-oiled machine at all. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed Nov 5 21:21:14 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Nov 2014 21:21:14 +0100 Subject: Tweeting for GnuPG Message-ID: <874mudo0ud.fsf@vigenere.g10code.de> Hi, I am looking for one or two people who would like to fill the @gnupg Twitter account with some life. I am not one of those short message people but Twitter seems to be a big deal these days. Thus if someone would be interested to post short stuff there on a regular base we can arrange for it. We have 1400 followers right now. Anyone? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 4tmuelle at informatik.uni-hamburg.de Wed Nov 5 19:17:12 2014 From: 4tmuelle at informatik.uni-hamburg.de (Tobias Mueller) Date: Wed, 5 Nov 2014 19:17:12 +0100 Subject: Non-interactively signing UIDs on a key Message-ID: <20141105181712.GA22500@informatik.uni-hamburg.de> Hello. While investigating the state of the art of Python bindings I came across the problem of signing other people's keys. For example, in https://github.com/isislovecruft/python-gnupg/issues/29 is a complaint about the behaviour of --sign-key: By default, --sign-key drops you into an interactive prompt asking Really sign all user IDs? (y/N) and afterwards, regardless of your answer, drops you off in the gpg> interactive prompt (where you have to type save and quit and so forth). By default (because it's meant to be automateable) python-gnupg uses --no-tty to disable all interactivity, and trying to use --sign-key with --no-tty will produce an error message saying gpg: Sorry, no terminal at all requested - can't get input. Further, gpg won't listen to you if you try to use anything like --no-tty --passphrase-fd 0 --sign-key or any of the other passphrase input options. Not to deter anyone, because I'll take all the help I can get, but this is not going to be a fun set of patches, I'm afraid. :/ In https://bitbucket.org/vinay.sajip/python-gnupg/issue/15/how-to-sign-a-key the author of that library states: Signing a key is not supported, as it involves back-and-forth interacting with the gpg executable (signing a key is part of the options for editing a key). If there were a way of doing it using a one-off command (e.g. providing the id of the public key to sign, the trust level, and the private key to sign with) then this could be implemented. With pygpgme, it seems at least possible to sign a key, but it doesn't look very convenient: http://bazaar.launchpad.net/~jamesh/pygpgme/trunk/view/head:/gpgme/editutil.py#L110 My question is: Is there indeed no (simple) way to sign a UID on a key non-interactively with GnuPG? If there is a way, how could it be used by the libraries mentioned above? Cheers, Tobi From wk at gnupg.org Wed Nov 5 22:09:57 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Nov 2014 22:09:57 +0100 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <545A846E.90206@digitalbrains.com> (Peter Lebbing's message of "Wed, 05 Nov 2014 21:11:26 +0100") References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> Message-ID: <87zjc5mk0q.fsf@vigenere.g10code.de> On Wed, 5 Nov 2014 21:11, peter at digitalbrains.com said: > As an aside, a pinentry for Qt is of no use when you use PuTTY to > connect to the server, unless you have a very specific setup. I think It might be worth to check whether there is an interest in running gpg on the server via Putty and have Putty forward the communication of gpg to a gpg-agent+pinentry running on Windows. I can't understand why anyone wants to use a Windows box to admin Unix servers, but the success of Putty shows that we Unix folks will soon be minority. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 5 22:12:07 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Nov 2014 22:12:07 +0100 Subject: Non-interactively signing UIDs on a key In-Reply-To: <20141105181712.GA22500@informatik.uni-hamburg.de> (Tobias Mueller's message of "Wed, 5 Nov 2014 19:17:12 +0100") References: <20141105181712.GA22500@informatik.uni-hamburg.de> Message-ID: <87vbmtmjx4.fsf@vigenere.g10code.de> On Wed, 5 Nov 2014 19:17, 4tmuelle at informatik.uni-hamburg.de said: > My question is: Is there indeed no (simple) way to sign a UID on a > key non-interactively with GnuPG? There will be one soon: https://gnupg.org/faq/whats-new-in-2.1.html#quickgen Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rob at aspman.info Wed Nov 5 23:02:32 2014 From: rob at aspman.info (rob at aspman.info) Date: Wed, 05 Nov 2014 22:02:32 +0000 Subject: Tweeting for GnuPG In-Reply-To: <874mudo0ud.fsf@vigenere.g10code.de> References: <874mudo0ud.fsf@vigenere.g10code.de> Message-ID: <7D227B09-2148-4D91-A98D-7D47DCE907FD@aspman.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 5 November 2014 20:21:14 GMT+00:00, Werner Koch wrote: >Hi, > >I am looking for one or two people who would like to fill the @gnupg >Twitter account with some life. > >I am not one of those short message people but Twitter seems to be a >big >deal these days. Thus if someone would be interested to post short >stuff there on a regular base we can arrange for it. We have 1400 >followers right now. Anyone? > > >Shalom-Salam, > > Werner > > >-- >Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users What kind of tweets we talking about? And are you after someone who will be relatively independent to fill the role, or will the info for tweeting be suggested before hand? I wouldn't mind a more active role in the gnupg community. As a non-programmer, I feel a bit useless at the moment just reading from the list. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -----BEGIN PGP SIGNATURE----- iQE7BAEBCAAlHhxSb2IgQW1iaWRnZSA8cm9iQGFzcG1hbi5pbmZvPgUCVFqeeAAK CRD64//KWUvNFXeFCACIrMt2TBY5GyScAGNk7/uwN/wuYsmga2RaAgAl6U7GNeha i3ntAXG9BcuNFqdqzdjrW/yRZo77Jc4EQbv4tvRWUWDNjAER/VFWW5yNH/tLquis Q4BswjrZaBdaLBvzg7sNi531Evte7AyDjoxnZ0TS5oNitIKMQ6xLg33GC2450D7x tty205EglwtZ4qfuAIfbXkzmNODMIa/yXfBjvTNC326Y5K1TPMilSD8telhU82Zm dgUQn1dJpRvdU/xcOgG7QV+tz9MqkPFbJYUjdqieLsNNrf/AywxzrrJUc9YBEwt5 BoAHa1zjBSE58ytOii52BGFeWTLksGjHRK8b/Yg+ =w5r2 -----END PGP SIGNATURE----- From wk at gnupg.org Thu Nov 6 10:01:51 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 10:01:51 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released Message-ID: <87ioisn1mo.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release: Version 2.1.0. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG-2.1 ======================= - The file "secring.gpg" is not anymore used to store the secret keys. Merging of secret keys is now supported. - All support for PGP-2 keys has been removed for security reasons. - The standard key generation interface is now much leaner. This will help a new user to quickly generate a suitable key. - Support for Elliptic Curve Cryptography (ECC) is now available. - Commands to create and sign keys from the command line without any extra prompts are now available. - The Pinentry may now show the new passphrase entry and the passphrase confirmation entry in one dialog. - There is no more need to manually start the gpg-agent. It is now started by any part of GnuPG as needed. - Problems with importing keys with the same long key id have been addressed. - The Dirmngr is now part of GnuPG proper and also takes care of accessing keyserver. - Keyserver pools are now handled in a smarter way. - A new format for locally storing the public keys is now used. This considerable speeds up operations on large keyrings. - Revocation certificates are now created by default. - Card support has been updated, new readers and token types are supported. - The format of the key listing has been changed to better identify the properties of a key. - The gpg-agent may now be used on Windows as a Pageant replacement for Putty in the same way it is used for years on Unix as ssh-agent replacement. - Creation of X.509 certificates has been improved. It is now also possible to export them directly in PKCS#8 and PEM format for use on TLS servers. A detailed description of the changes can be found at https://gnupg.org/faq/whats-new-in-2.1.html . Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig This is the GnuPG 2.1 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig This is an experimental installer for Windows including GPA as graphical key manager and GpgEX as an Explorer extension. Please de-install an already installed Gpg4win version before trying this installer. This binary version has not been tested very well, thus it is likely that you will run into problems. The complete source code for the software included in this installer is in the same directory; use the suffix ".tar.xz" instead of ".exe". Although several beta versions have been released over the course of the last years, no extensive public field test has been done. Thus it is likely that bugs will show up. Please check the mailing list archives and the new wiki https://wiki.gnupg.org for latest information on known problems and workaround. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.0.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.0.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.0.tar.bz2 and check that the output matches the first line from the following list: 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Internationalization ==================== This new branch of GnuPG has support for 4 languages: French, German, Japanese, and Ukrainian. More translations can be expected with the next point releases. Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. A final big Thank You goes to Hal Finney, who too early passed away this year. Hal worked on PGP and helped to make OpenPGP a great standard; it has been a pleasure having worked with him. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ravikumar.SubramaniaRao at netapp.com Wed Nov 5 20:52:15 2014 From: ravikumar.SubramaniaRao at netapp.com (SubramaniaRao, ravikumar) Date: Wed, 5 Nov 2014 19:52:15 +0000 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> Message-ID: <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> Peter, Thank for your Input. Please help me where I will get the tar File for Qt pinentry, so that I can install it. If QT Pinetry is not required, when I try to set up the Passphrase I get this error gpg-agent[7931]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[7931]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: Key generation canceled. Cheers, S. Ravi Kumar -----Original Message----- From: Peter Lebbing [mailto:peter at digitalbrains.com] Sent: Wednesday, November 05, 2014 7:15 AM To: SubramaniaRao, ravikumar Cc: gnupg-users at gnupg.org Subject: RE: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 > Sorry, it was not the intention to advertise the Phrase or using a > Famous Passphrase. I wanted to show after giving the Passphrase it was > hanging. So I showed that in the Screen Shot. We wanted the Resolution > for this. You weren't entering a passhprase there. If it were asking for a passphrase, it wouldn't show your typing. Instead, your input was most likely simply not processed and echoed on the terminal. Try this and see what I mean: $ sleep 10 Just type anything interesting in the 10 seconds the program sleeps $ Just type anything interesting in the 10 seconds the program sleeps That last line will be the new prompt with what you just typed echoed /again/, as it is now processing your input and using it as the command line. > Yes we access the System Remotely and we tried to install the > Pinentry. But it gave the error . Are you sure there is an error? I interpreted it as that the Qt pinentry was simply not built, but the others, and the wanted curses pinentry was. Were there any binaries generated by the build? > CURSES PINENTRY ..: YES > TTY PINENTRY .....: MAYBE > GTK+ PINENTRY ....: YES > GTK+-2 PINENTRY ..: YES > QT PINENTRY ......: NO > QT4 PINENTRY .....: NO > W32 PINENTRY .....: NO > > FALLBACK TO CURSES: YES > > DEFAULT PINENTRY .: PINENTRY-GTK-2 See? If it's not going to build the Qt version, why would it need any Qt headers? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravikumar.SubramaniaRao at netapp.com Wed Nov 5 22:13:52 2014 From: ravikumar.SubramaniaRao at netapp.com (SubramaniaRao, ravikumar) Date: Wed, 5 Nov 2014 21:13:52 +0000 Subject: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 In-Reply-To: <87zjc5mk0q.fsf@vigenere.g10code.de> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> Message-ID: <5d4d37ea57df4fe0a8c4b10add18e571@hioexcmbx04-prd.hq.netapp.com> Koch, Thank you fir your Help. Yes we are using putty only. Not any Graphical. But it complains that You need a Passphrase to protect your secret key. gpg-agent[7931]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[7931]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: Key generation canceled. We do not know why it gives this error when QTPinentry is not required. Cheers, S. Ravi Kumar -----Original Message----- From: Werner Koch [mailto:wk at gnupg.org] Sent: Wednesday, November 05, 2014 1:10 PM To: Peter Lebbing Cc: SubramaniaRao, ravikumar; gnupg-users at gnupg.org Subject: Re: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10 On Wed, 5 Nov 2014 21:11, peter at digitalbrains.com said: > As an aside, a pinentry for Qt is of no use when you use PuTTY to > connect to the server, unless you have a very specific setup. I think It might be worth to check whether there is an interest in running gpg on the server via Putty and have Putty forward the communication of gpg to a gpg-agent+pinentry running on Windows. I can't understand why anyone wants to use a Windows box to admin Unix servers, but the success of Putty shows that we Unix folks will soon be minority. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.cole at gmail.com Thu Nov 6 12:18:48 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 6 Nov 2014 11:18:48 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: Hi Werner, Building on OS X using make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local gets what looks like most of the way and then fails with the error shown below. Am I the only person experiencing this, or are others hitting the same problem? Best wishes, N. Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[5]: *** [t-sexputil] Error 1 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [all] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/nicholas/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 On Thu, Nov 6, 2014 at 9:01 AM, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a > new release: Version 2.1.0. > > The GNU Privacy Guard (GnuPG) is a complete and free implementation of > the OpenPGP standard as defined by RFC-4880 and better known as PGP. > > GnuPG, also known as GPG, allows to encrypt and sign data and > communication, features a versatile key management system as well as > access modules for public key directories. GnuPG itself is a command > line tool with features for easy integration with other applications. > A wealth of frontend applications and libraries making use of GnuPG > are available. Since version 2 GnuPG provides support for S/MIME and > Secure Shell in addition to OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > Three different versions of GnuPG are actively maintained: > > - GnuPG "modern" (2.1) is the latest development with a lot of new > features. This announcement is about the first release of this > version. > > - GnuPG "stable" (2.0) is the current stable version for general use. > This is what most users are currently using. > > - GnuPG "classic" (1.4) is the old standalone version which is most > suitable for older or embedded platforms. > > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. > > > What's New in GnuPG-2.1 > ======================= > > - The file "secring.gpg" is not anymore used to store the secret > keys. Merging of secret keys is now supported. > > - All support for PGP-2 keys has been removed for security reasons. > > - The standard key generation interface is now much leaner. This > will help a new user to quickly generate a suitable key. > > - Support for Elliptic Curve Cryptography (ECC) is now available. > > - Commands to create and sign keys from the command line without any > extra prompts are now available. > > - The Pinentry may now show the new passphrase entry and the > passphrase confirmation entry in one dialog. > > - There is no more need to manually start the gpg-agent. It is now > started by any part of GnuPG as needed. > > - Problems with importing keys with the same long key id have been > addressed. > > - The Dirmngr is now part of GnuPG proper and also takes care of > accessing keyserver. > > - Keyserver pools are now handled in a smarter way. > > - A new format for locally storing the public keys is now used. > This considerable speeds up operations on large keyrings. > > - Revocation certificates are now created by default. > > - Card support has been updated, new readers and token types are > supported. > > - The format of the key listing has been changed to better identify > the properties of a key. > > - The gpg-agent may now be used on Windows as a Pageant replacement > for Putty in the same way it is used for years on Unix as > ssh-agent replacement. > > - Creation of X.509 certificates has been improved. It is now also > possible to export them directly in PKCS#8 and PEM format for use > on TLS servers. > > A detailed description of the changes can be found at > https://gnupg.org/faq/whats-new-in-2.1.html . > > > Getting the Software > ==================== > > Please follow the instructions found at https://gnupg.org/download/ or > read on: > > GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found > at https://gnupg.org/mirrors.html . Note that GnuPG is not available > at ftp.gnu.org. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig > > This is the GnuPG 2.1 source code compressed using BZIP2 and its > OpenPGP signature. > > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig > > This is an experimental installer for Windows including GPA as > graphical key manager and GpgEX as an Explorer extension. Please > de-install an already installed Gpg4win version before trying this > installer. This binary version has not been tested very well, thus it > is likely that you will run into problems. The complete source code > for the software included in this installer is in the same directory; > use the suffix ".tar.xz" instead of ".exe". > > Although several beta versions have been released over the course of > the last years, no extensive public field test has been done. Thus it > is likely that bugs will show up. Please check the mailing list > archives and the new wiki https://wiki.gnupg.org for latest > information on known problems and workaround. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.0.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.0.tar.bz2.sig > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by one or more of the release signing keys. Make sure that > this is a valid key, either by matching the shown fingerprint > against a trustworthy list of valid release signing keys or by > checking that the key has been signed by trustworthy other keys. > See below for information on the signing keys. > > * If you are not able to use an existing version of GnuPG, you have > to verify the SHA-1 checksum. On Unix systems the command to do > this is either "sha1sum" or "shasum". Assuming you downloaded the > file gnupg-2.1.0.tar.bz2, you would run the command like this: > > sha1sum gnupg-2.1.0.tar.bz2 > > and check that the output matches the first line from the > following list: > > 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 > 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe > 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz > > > Release Signing Keys > ==================== > > To guarantee that a downloaded GnuPG version has not been tampered by > malicious entities we provide signature files for all tarballs and > binary versions. The keys are also signed by the long term keys of > their respective owners. Current releases are signed by one or more > of these four keys: > > 2048R/4F25E3B6 2011-01-12 > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048/E0856959 2014-10-29 > Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 > David Shaw (GnuPG Release Signing Key) > > rsa2048/33BD3F06 2014-10-29 > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa2048/7EFD60D9 2014-10-19 > Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 > Werner Koch (Release Signing Key) > > You may retrieve these files from the keyservers using this command > > gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ > 2071B08A33BD3F06 8A861B1C7EFD60D9 > > The keys are also available at https://gnupg.org/signature_key.html > and in the released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed using my standard PGP key. > > > Internationalization > ==================== > > This new branch of GnuPG has support for 4 languages: French, German, > Japanese, and Ukrainian. More translations can be expected with the > next point releases. > > > Documentation > ============= > > If you used GnuPG in the past you should read the description of > changes and new features at doc/whats-new-in-2.1.txt or online at > > https://gnupg.org/faq/whats-new-in-2.1.html > > The file gnupg.info has the complete user manual of the system. > Separate man pages are included as well but they have not all the > details available in the manual. It is also possible to read the > complete manual online in HTML format at > > https://gnupg.org/documentation/manuals/gnupg/ > > or in Portable Document Format at > > https://gnupg.org/documentation/manuals/gnupg.pdf . > > The chapters on gpg-agent, gpg and gpgsm include information on how > to set up the whole thing. You may also want search the GnuPG mailing > list archives or ask on the gnupg-users mailing lists for advise on > how to solve problems. Many of the new features are around for > several years and thus enough public knowledge is already available. > > > Support > ======= > > Please consult the archive of the gnupg-users mailing list before > reporting a bug . > We suggest to send bug reports for a new release to this list in favor > of filing a bug at . For commercial support > requests we keep a list of known service companies at: > > https://gnupg.org/service.html > > The driving force behind the development of GnuPG is the company of > its principal author, Werner Koch. Maintenance and improvement of > GnuPG and related software takes up most of their resources. To allow > him to continue this work he kindly asks to either purchase a support > contract, engage g10 Code for custom enhancements, or to donate money: > > https://gnupg.org/donate/ > > > Thanks > ====== > > We have to thank all the people who helped with this release, be it > testing, coding, translating, suggesting, auditing, administering the > servers, spreading the word, and answering questions on the mailing > lists. A final big Thank You goes to Hal Finney, who too early passed > away this year. Hal worked on PGP and helped to make OpenPGP a great > standard; it has been a pleasure having worked with him. > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From mailinglisten at hauke-laging.de Thu Nov 6 14:16:07 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 06 Nov 2014 14:16:07 +0100 Subject: problem with the archive for gnupg-announce Message-ID: <3436003.bEqyf0xlOW@inno> Hello, on http://lists.gnupg.org/mailman/listinfo/gnupg-announce there is a link to the archive http://lists.gnupg.org/pipermail/gnupg-announce but that does not work; it's a strange redirect to http://lists.gnupg.org:8002/pipermail/gnupg-announce/ Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From peter at digitalbrains.com Thu Nov 6 14:25:21 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 06 Nov 2014 14:25:21 +0100 Subject: gpg-agent forwarding (was Re: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10) In-Reply-To: <87zjc5mk0q.fsf@vigenere.g10code.de> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> Message-ID: <545B76C1.4090608@digitalbrains.com> On 05/11/14 22:09, Werner Koch wrote: > It might be worth to check whether there is an interest in running gpg on > the server via Putty and have Putty forward the communication of gpg to > a gpg-agent+pinentry running on Windows. I think this certainly has its upsides, running the agent on the console of the user instead of the system they ssh into. If the agent is simply used as a method of password entry, the password is passed over the SSH connection just as it is when entering the password in a curses pinentry running on the system where gpg runs. When it's used with a smartcard, this would mean the user can use it on his console, possibly even entering the PIN on the pinpad of the reader. When it's used as it is in GnuPG 2.1, the whole setup changes (as it does for the smartcard, btw), because now the private key needs to be on the console instead of the server running gpg. But there are security issues. How would this be implemented? I can think of two options: a TCP port, forwarded by PuTTY, and an SSH subsystem. Assume it's a TCP port listening on the console. A TCP port is accessible by anyone. Even when you restrict it to localhost, this exposes it to any other user on a multi-user system. With the traditional setup, I think usually only root/admin/... and the intended user can access an agent. On Linux, I think you can get the owner of the socket, so you could simply verify the UID. But this is non-portable. When you use a cookie to control access, you need a way to get that cookie to the server where gpg is running. This could be solved by instructing the user to copy the text of the cookie, presented by a pinentry dialog, to the server. A separate helper "gpg-setup-cookie" perhaps, invoked sometime after the user logs in (or when they do) and before they use gpg. Additionally, I think a TCP port might tempt people to construct truly unsafe constructions, where the port is not forwarded by an SSH client or otherwise suitably protected. But perhaps an SSH subsystem is a nice alternative? This would change the direction of initiation: the agent would need to connect to the server via SSH. But it does include full user authentication and provides a secure channel. An SSH subsystem is, broadly, simply an SSH connection, but instead of starting a shell and sending standard input and standard output over the SSH channel, it starts a specified command with its stdin and stdout sent over the SSH channel. This is also possible without using a subsystem, but subsystems are specifically tailored to SSH. Though maybe their primary feature is the possibility to enable access to subsystems without enabling shell access, which is not needed in this case. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Thu Nov 6 15:09:28 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 15:09:28 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: (Nicholas Cole's message of "Thu, 6 Nov 2014 11:18:48 +0000") References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <87sihwju93.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 12:18, nicholas.cole at gmail.com said: > make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local Actually is is INSTALL_PREFIX - I posted a wrong name once. > gets what looks like most of the way and then fails with the error > shown below. Am I the only person experiencing this, or are others According a another OS X developer, the last beta worked just fine. > Undefined symbols for architecture x86_64: > > "_default_errsource", referenced from: > make[5]: *** [t-sexputil] Error 1 default_errsource is defined by init.c which is included in libcommon.a which in turn is part of the objects linked to t-sexputil. Thus there should be no problems. Someone (but not me) needs to have a look at the build log. Shalom-Salam, Werner p.s. I removed gnupg-devel@ becuase I do think it makes sense to cross-post. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 15:41:49 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 15:41:49 +0100 Subject: problem with the archive for gnupg-announce In-Reply-To: <3436003.bEqyf0xlOW@inno> (Hauke Laging's message of "Thu, 06 Nov 2014 14:16:07 +0100") References: <3436003.bEqyf0xlOW@inno> Message-ID: <87fvdwjsr6.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 14:16, mailinglisten at hauke-laging.de said: > but that does not work; it's a strange redirect to > http://lists.gnupg.org:8002/pipermail/gnupg-announce/ It is not strange but the usual way to run a load balancer. I know that bug and there is even an entry in the tracker. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 15:40:13 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 15:40:13 +0100 Subject: gpg-agent forwarding In-Reply-To: <545B76C1.4090608@digitalbrains.com> (Peter Lebbing's message of "Thu, 06 Nov 2014 14:25:21 +0100") References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> <545B76C1.4090608@digitalbrains.com> Message-ID: <87k338jstt.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 14:25, peter at digitalbrains.com said: > How would this be implemented? I can think of two options: a TCP port, > forwarded by PuTTY, and an SSH subsystem. OpenSSH has socket forwarding and that is what I was thinking about. Similar to a subsystem it uses a channel on the ssh connection for the transport. Assuming that OpenSSH is running on the server, what we need is a limited client side implementation of socket forwaring in Putty; Putty would then translate that to an Windows IPC mechnism (e.g. local TCP+nonce) and gpg-agent can immediatley use it. In fact I plan to add an option to gpg-agent to open a second listing socket which can be used for such forwarding. Connection via that socket would be restricted in that not all gpg-agent features are available (e.g. no passphrase cache). > A TCP port is accessible by anyone. Even when you restrict it to > localhost, this exposes it to any other user on a multi-user system. Only to those who have the permissions to switch the socket into promiscuous mode to run tcpdump. That is usually only root. Even on Windows other user can't tap an established TCP connection. To avoid that other users connect to a listening socket we use a nonce taken from a file - that file is protected by the usual file system permissions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 15:45:58 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 15:45:58 +0100 Subject: problem with the archive for gnupg-announce In-Reply-To: <3436003.bEqyf0xlOW@inno> (Hauke Laging's message of "Thu, 06 Nov 2014 14:16:07 +0100") References: <3436003.bEqyf0xlOW@inno> Message-ID: <87bnokjsk9.fsf@vigenere.g10code.de> Fixed. Appending a slash to the URL was sufficient to avoid the rewrite. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Thu Nov 6 15:56:18 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 06 Nov 2014 15:56:18 +0100 Subject: What's new in 2.1 FAQ: Corrections, suggestions Message-ID: <545B8C12.2050007@digitalbrains.com> Hello Werner and list, While reading that FAQ top to bottom, I encountered some typo's which I fixed. I'm only used to git in a non-distributed fashion, so I'm not accustomed to it's patch submission features and simply attach a git-generated diff against 0968808. I hope that suffises. And perhaps this needs clarification: > The fingerprint may also be given without the spaces in which case > there is no need for the quotes. If you want to sign only certain > user ids of a key, list those user id verbatim after the > fingerprint. When I read this, I think, do I need this: $ gpg2 --quick-sign-key '15CB 723E 2000 A1A8 2505 F3B7 CC00 B501 BD19 AC1C Daniel Ellsberg ' Or do I need this: $ gpg2 --quick-sign-key '15CB 723E 2000 A1A8 2505 F3B7 CC00 B501 BD19 AC1C' 'Daniel Ellsberg ' In other words, is it one argument or two arguments? I'd be inclined to the latter when thinking how I would design this, but I'm inclined to the former by the phrasing "after the fingerprint". An example would remove ambiguity. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: whats-new-in-2.1.org.diff Type: text/x-patch Size: 4064 bytes Desc: not available URL: From shmick at riseup.net Thu Nov 6 16:05:20 2014 From: shmick at riseup.net (shmick at riseup.net) Date: Fri, 07 Nov 2014 02:05:20 +1100 Subject: Tweeting for GnuPG In-Reply-To: <874mudo0ud.fsf@vigenere.g10code.de> References: <874mudo0ud.fsf@vigenere.g10code.de> Message-ID: <545B8E30.7080409@riseup.net> Werner Koch: > I am not one of those short message people but you're not a twittiot ? respect From peter at digitalbrains.com Thu Nov 6 16:09:01 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 06 Nov 2014 16:09:01 +0100 Subject: gpg-agent forwarding In-Reply-To: <87k338jstt.fsf@vigenere.g10code.de> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> <545B76C1.4090608@digitalbrains.com> <87k338jstt.fsf@vigenere.g10code.de> Message-ID: <545B8F0D.3040901@digitalbrains.com> On 06/11/14 15:40, Werner Koch wrote: > OpenSSH has socket forwarding and that is what I was thinking about. Sockets other than TCP you mean? Is this something generic that can be invoked by using the command-line OpenSSH client? I can't find it. > To avoid that other users connect to a listening socket we use a > nonce taken from a file - that file is protected by the usual file > system permissions. Right, connecting to it was what I was referring to. And since I was thinking about just using a forwarded TCP connection, the nonce/cookie needed to be known to gpg running on the server, hence my elaborate construction. If you include functionality inside the SSH client, this is obviously not needed. Were you thinking of writing that functionality for OpenSSH on Linux as well? Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailing-lists at asatiifm.net Thu Nov 6 15:14:57 2014 From: mailing-lists at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Thu, 6 Nov 2014 16:14:57 +0200 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: Hi, I can?t use speedo.mk as I get "GnuPG has already been build[sic] in-source?. I?m not going to replace 2.0 at this time so I won?t remove it. With just ?make? I get an error on linking libgpg-error. I happen to have versions 0.16 and 0.17 but not 0.13 under the referenced path. [shell quote] gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libassuan/2.1.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libksba/1.3.1/include -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [t-sexputil] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 [/shell quote] -- Ville On 6 Nov 2014, at 13:18, Nicholas Cole wrote: > Hi Werner, > > Building on OS X using > > make -f build-aux/speedo.mk native INSTALL_DIR=/usr/local > > gets what looks like most of the way and then fails with the error > shown below. Am I the only person experiencing this, or are others > hitting the same problem? > > Best wishes, > > N. > > > > Undefined symbols for architecture x86_64: > > "_default_errsource", referenced from: > > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > > ld: symbol(s) not found for architecture x86_64 > > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > make[5]: *** [t-sexputil] Error 1 > > make[5]: *** Waiting for unfinished jobs.... > > make[4]: *** [all] Error 2 > > make[3]: *** [all-recursive] Error 1 > > make[2]: *** [all] Error 2 > > make[1]: *** [/Users/nicholas/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] > Error 2 > > make: *** [native] Error 2 > > On Thu, Nov 6, 2014 at 9:01 AM, Werner Koch wrote: >> Hello! >> >> The GnuPG Project is pleased to announce the availability of a >> new release: Version 2.1.0. >> >> The GNU Privacy Guard (GnuPG) is a complete and free implementation of >> the OpenPGP standard as defined by RFC-4880 and better known as PGP. >> >> GnuPG, also known as GPG, allows to encrypt and sign data and >> communication, features a versatile key management system as well as >> access modules for public key directories. GnuPG itself is a command >> line tool with features for easy integration with other applications. >> A wealth of frontend applications and libraries making use of GnuPG >> are available. Since version 2 GnuPG provides support for S/MIME and >> Secure Shell in addition to OpenPGP. >> >> GnuPG is Free Software (meaning that it respects your freedom). It can >> be freely used, modified and distributed under the terms of the GNU >> General Public License. >> >> Three different versions of GnuPG are actively maintained: >> >> - GnuPG "modern" (2.1) is the latest development with a lot of new >> features. This announcement is about the first release of this >> version. >> >> - GnuPG "stable" (2.0) is the current stable version for general use. >> This is what most users are currently using. >> >> - GnuPG "classic" (1.4) is the old standalone version which is most >> suitable for older or embedded platforms. >> >> You may not install "modern" (2.1) and "stable" (2.0) at the same >> time. However, it is possible to install "classic" (1.4) along with >> any of the other versions. >> >> >> What's New in GnuPG-2.1 >> ======================= >> >> - The file "secring.gpg" is not anymore used to store the secret >> keys. Merging of secret keys is now supported. >> >> - All support for PGP-2 keys has been removed for security reasons. >> >> - The standard key generation interface is now much leaner. This >> will help a new user to quickly generate a suitable key. >> >> - Support for Elliptic Curve Cryptography (ECC) is now available. >> >> - Commands to create and sign keys from the command line without any >> extra prompts are now available. >> >> - The Pinentry may now show the new passphrase entry and the >> passphrase confirmation entry in one dialog. >> >> - There is no more need to manually start the gpg-agent. It is now >> started by any part of GnuPG as needed. >> >> - Problems with importing keys with the same long key id have been >> addressed. >> >> - The Dirmngr is now part of GnuPG proper and also takes care of >> accessing keyserver. >> >> - Keyserver pools are now handled in a smarter way. >> >> - A new format for locally storing the public keys is now used. >> This considerable speeds up operations on large keyrings. >> >> - Revocation certificates are now created by default. >> >> - Card support has been updated, new readers and token types are >> supported. >> >> - The format of the key listing has been changed to better identify >> the properties of a key. >> >> - The gpg-agent may now be used on Windows as a Pageant replacement >> for Putty in the same way it is used for years on Unix as >> ssh-agent replacement. >> >> - Creation of X.509 certificates has been improved. It is now also >> possible to export them directly in PKCS#8 and PEM format for use >> on TLS servers. >> >> A detailed description of the changes can be found at >> https://gnupg.org/faq/whats-new-in-2.1.html . >> >> >> Getting the Software >> ==================== >> >> Please follow the instructions found at https://gnupg.org/download/ or >> read on: >> >> GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or >> direct from its primary FTP server. The list of mirrors can be found >> at https://gnupg.org/mirrors.html . Note that GnuPG is not available >> at ftp.gnu.org. >> >> On ftp.gnupg.org you find these files: >> >> ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) >> ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig >> >> This is the GnuPG 2.1 source code compressed using BZIP2 and its >> OpenPGP signature. >> >> ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) >> ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig >> >> This is an experimental installer for Windows including GPA as >> graphical key manager and GpgEX as an Explorer extension. Please >> de-install an already installed Gpg4win version before trying this >> installer. This binary version has not been tested very well, thus it >> is likely that you will run into problems. The complete source code >> for the software included in this installer is in the same directory; >> use the suffix ".tar.xz" instead of ".exe". >> >> Although several beta versions have been released over the course of >> the last years, no extensive public field test has been done. Thus it >> is likely that bugs will show up. Please check the mailing list >> archives and the new wiki https://wiki.gnupg.org for latest >> information on known problems and workaround. >> >> >> Checking the Integrity >> ====================== >> >> In order to check that the version of GnuPG which you are going to >> install is an original and unmodified one, you can do it in one of >> the following ways: >> >> * If you already have a version of GnuPG installed, you can simply >> verify the supplied signature. For example to verify the signature >> of the file gnupg-2.1.0.tar.bz2 you would use this command: >> >> gpg --verify gnupg-2.1.0.tar.bz2.sig >> >> This checks whether the signature file matches the source file. >> You should see a message indicating that the signature is good and >> made by one or more of the release signing keys. Make sure that >> this is a valid key, either by matching the shown fingerprint >> against a trustworthy list of valid release signing keys or by >> checking that the key has been signed by trustworthy other keys. >> See below for information on the signing keys. >> >> * If you are not able to use an existing version of GnuPG, you have >> to verify the SHA-1 checksum. On Unix systems the command to do >> this is either "sha1sum" or "shasum". Assuming you downloaded the >> file gnupg-2.1.0.tar.bz2, you would run the command like this: >> >> sha1sum gnupg-2.1.0.tar.bz2 >> >> and check that the output matches the first line from the >> following list: >> >> 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 >> 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe >> 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz >> >> >> Release Signing Keys >> ==================== >> >> To guarantee that a downloaded GnuPG version has not been tampered by >> malicious entities we provide signature files for all tarballs and >> binary versions. The keys are also signed by the long term keys of >> their respective owners. Current releases are signed by one or more >> of these four keys: >> >> 2048R/4F25E3B6 2011-01-12 >> Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 >> Werner Koch (dist sig) >> >> rsa2048/E0856959 2014-10-29 >> Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 >> David Shaw (GnuPG Release Signing Key) >> >> rsa2048/33BD3F06 2014-10-29 >> Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 >> NIIBE Yutaka (GnuPG Release Key) >> >> rsa2048/7EFD60D9 2014-10-19 >> Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 >> Werner Koch (Release Signing Key) >> >> You may retrieve these files from the keyservers using this command >> >> gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ >> 2071B08A33BD3F06 8A861B1C7EFD60D9 >> >> The keys are also available at https://gnupg.org/signature_key.html >> and in the released GnuPG tarball in the file g10/distsigkey.gpg . >> Note that this mail has been signed using my standard PGP key. >> >> >> Internationalization >> ==================== >> >> This new branch of GnuPG has support for 4 languages: French, German, >> Japanese, and Ukrainian. More translations can be expected with the >> next point releases. >> >> >> Documentation >> ============= >> >> If you used GnuPG in the past you should read the description of >> changes and new features at doc/whats-new-in-2.1.txt or online at >> >> https://gnupg.org/faq/whats-new-in-2.1.html >> >> The file gnupg.info has the complete user manual of the system. >> Separate man pages are included as well but they have not all the >> details available in the manual. It is also possible to read the >> complete manual online in HTML format at >> >> https://gnupg.org/documentation/manuals/gnupg/ >> >> or in Portable Document Format at >> >> https://gnupg.org/documentation/manuals/gnupg.pdf . >> >> The chapters on gpg-agent, gpg and gpgsm include information on how >> to set up the whole thing. You may also want search the GnuPG mailing >> list archives or ask on the gnupg-users mailing lists for advise on >> how to solve problems. Many of the new features are around for >> several years and thus enough public knowledge is already available. >> >> >> Support >> ======= >> >> Please consult the archive of the gnupg-users mailing list before >> reporting a bug . >> We suggest to send bug reports for a new release to this list in favor >> of filing a bug at . For commercial support >> requests we keep a list of known service companies at: >> >> https://gnupg.org/service.html >> >> The driving force behind the development of GnuPG is the company of >> its principal author, Werner Koch. Maintenance and improvement of >> GnuPG and related software takes up most of their resources. To allow >> him to continue this work he kindly asks to either purchase a support >> contract, engage g10 Code for custom enhancements, or to donate money: >> >> https://gnupg.org/donate/ >> >> >> Thanks >> ====== >> >> We have to thank all the people who helped with this release, be it >> testing, coding, translating, suggesting, auditing, administering the >> servers, spreading the word, and answering questions on the mailing >> lists. A final big Thank You goes to Hal Finney, who too early passed >> away this year. Hal worked on PGP and helped to make OpenPGP a great >> standard; it has been a pleasure having worked with him. >> >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> _______________________________________________ >> Gnupg-announce mailing list >> Gnupg-announce at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-announce >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From peter at digitalbrains.com Thu Nov 6 16:15:57 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 06 Nov 2014 16:15:57 +0100 Subject: (OT) Re: What's new in 2.1 FAQ: Corrections, suggestions In-Reply-To: <545B8C12.2050007@digitalbrains.com> References: <545B8C12.2050007@digitalbrains.com> Message-ID: <545B90AD.4020607@digitalbrains.com> > so I'm not accustomed to it's patch submission features Ah, I'm glad to see Muphry's Law is still in effect. The world works the way it's supposed to. ;) Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailing-lists at asatiifm.net Thu Nov 6 15:22:36 2014 From: mailing-lists at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Thu, 6 Nov 2014 16:22:36 +0200 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87sihwju93.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87sihwju93.fsf@vigenere.g10code.de> Message-ID: Ok I did distclean and here?s the results of speedo for me. Again, libgpg-error version 0.13 seems to be on the wish list: ld: warning: ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' CCLD t-convert CCLD t-percent CCLD t-gettime ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' CCLD t-sysutils CCLD t-sexputil CCLD t-session-env ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[5]: *** [t-sexputil] Error 1 make[5]: *** Waiting for unfinished jobs.... CCLD t-openpgp-oid ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' make[4]: *** [all] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [/Users/vmaatta/Downloads/gnupg-2.1.0/PLAY/stamps/stamp-gnupg-02-make] Error 2 make: *** [native] Error 2 On 6 Nov 2014, at 16:14, Ville M??tt? wrote: > [shell quote] > > gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libassuan/2.1.2/include -I/usr/local/Cellar/libgpg-error/1.13/include -I/usr/local/Cellar/libksba/1.3.1/include -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv > ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' > ld: warning: directory not found for option '-L/usr/local/Cellar/libgpg-error/1.13/lib' > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[3]: *** [t-sexputil] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > [/shell quote] -- Ville On 6 Nov 2014, at 16:09, Werner Koch wrote: >> Undefined symbols for architecture x86_64: >> >> "_default_errsource", referenced from: > > >> make[5]: *** [t-sexputil] Error 1 > > default_errsource is defined by init.c which is included in libcommon.a > which in turn is part of the objects linked to t-sexputil. Thus there > should be no problems. Someone (but not me) needs to have a look at the > build log. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rjh at sixdemonbag.org Thu Nov 6 16:58:31 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 10:58:31 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems Message-ID: <545B9AA7.2070603@sixdemonbag.org> There's an odd problem with 2.1.0 on Win32. Steps: 1. Uninstall existing gpg4win. 2. Install the new experimental 2.1.0 Windows installer. 3. Try to pull a key from a keyserver such as: ===== C:\utils>gpg --keyserver pool.sks-keyservers.net --recv-key d5078b4f gpg: keyserver receive failed: Input/output error ===== I made no changes to my gpg.conf file nor to my keyring. I've confirmed that I have network connectivity and I can hit http://pool.sks-keyservers.net. From rjh at sixdemonbag.org Thu Nov 6 17:12:04 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 11:12:04 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9AA7.2070603@sixdemonbag.org> References: <545B9AA7.2070603@sixdemonbag.org> Message-ID: <545B9DD4.3020500@sixdemonbag.org> > I made no changes to my gpg.conf file nor to my keyring. I've confirmed > that I have network connectivity and I can hit > http://pool.sks-keyservers.net. Next round of problems: doing a --list-secret-keys takes considerable time -- approximately 28 seconds on a fairly modern desktop. --list-keys, though, is pretty snappy. From dkg at fifthhorseman.net Thu Nov 6 17:17:11 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Nov 2014 11:17:11 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9DD4.3020500@sixdemonbag.org> References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> Message-ID: <545B9F07.40705@fifthhorseman.net> On 11/06/2014 11:12 AM, Robert J. Hansen wrote: >> I made no changes to my gpg.conf file nor to my keyring. I've confirmed >> that I have network connectivity and I can hit >> http://pool.sks-keyservers.net. > > Next round of problems: doing a --list-secret-keys takes considerable > time -- approximately 28 seconds on a fairly modern desktop. > --list-keys, though, is pretty snappy. have you converted your keyring to pubring.kbx and moved away the old pubring.gpg? This was discussed already on gnupg-devel on 10 oct 2014 (subject: performance of gpg --list-secret-keys with large keyrings) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From avi.wiki at gmail.com Thu Nov 6 16:15:07 2014 From: avi.wiki at gmail.com (Avi) Date: Thu, 6 Nov 2014 10:15:07 -0500 Subject: With the release of modern, is there intent to support ECC in classic? Message-ID: Good morning/afternoon/evening. I know that this has been discussed previously, but now that GnuPG modern has been released with ECC support, is there the intention to add that support to the classic build in the near-to-internediate future? Thank you, Avi ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Nov 6 17:34:47 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 17:34:47 +0100 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9F07.40705@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 06 Nov 2014 11:17:11 -0500") References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> <545B9F07.40705@fifthhorseman.net> Message-ID: <87wq78gue0.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 17:17, dkg at fifthhorseman.net said: > have you converted your keyring to pubring.kbx and moved away the old > pubring.gpg? That was not the problem. I think the real problem was that the code to check whether a secret key exists parsed the entire rest of the keyring to find matching subkeys. I fixed this a few days ago. I don't know why on windows it is that slow - but good catch by Rob. As I said I have not tested the installer very well - in particular not with a large keyring. On Unix I do not see that problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Thu Nov 6 17:44:43 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 11:44:43 -0500 Subject: With the release of modern, is there intent to support ECC in classic? In-Reply-To: References: Message-ID: <545BA57B.7090905@sixdemonbag.org> > I know that this has been discussed previously, but now that GnuPG > modern has been released with ECC support, is there the intention to > add that support to the classic build in the near-to-internediate > future? The last this was discussed the answer was "no". It's been some months since then, but I haven't seen anything to make me think the answer has changed. Sorry. :( From wk at gnupg.org Thu Nov 6 17:42:01 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 17:42:01 +0100 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9AA7.2070603@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 06 Nov 2014 10:58:31 -0500") References: <545B9AA7.2070603@sixdemonbag.org> Message-ID: <87sihwgu1y.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 16:58, rjh at sixdemonbag.org said: > C:\utils>gpg --keyserver pool.sks-keyservers.net --recv-key d5078b4f > gpg: keyserver receive failed: Input/output error Okay, I need to debug this. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Nov 6 17:47:00 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 6 Nov 2014 17:47:00 +0100 Subject: EFF's Secure Messaging Scorecard Message-ID: <201411061747.07179.bernhard@intevation.de> EFF's Secure Messaging Scorecard mentions Ggp4win, I've added it here and also started with some comments on their evaluation: http://wiki.gnupg.org/press -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Thu Nov 6 17:49:17 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 11:49:17 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9F07.40705@fifthhorseman.net> References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> <545B9F07.40705@fifthhorseman.net> Message-ID: <545BA68D.9020303@sixdemonbag.org> > have you converted your keyring to pubring.kbx and moved away the old > pubring.gpg? I started from a brand new install, right down to emptying out my old %APPDATA%\Roaming\GnuPG directory. I reloaded keys the "hard" way, by --import \path\to\old\pubring.gpg and --import \path\to\old\secring.gpg. As near as I can tell I'm doing things correctly. However, honesty compels me to say that I'm running into a *lot* of problems with the Windows build. It does not appear to me to be ready for prime time. > This was discussed already on gnupg-devel on 10 oct 2014 (subject: > performance of gpg --list-secret-keys with large keyrings) Yes, which is why I reported it again: because I was under the impression that bug had been *fixed*. From wk at gnupg.org Thu Nov 6 17:48:06 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 17:48:06 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: ("Ville =?utf-8?B?TcOkw6R0dMOkIidz?= message of "Thu, 6 Nov 2014 16:14:57 +0200") References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <87k338gtrt.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 15:14, mailing-lists at asatiifm.net said: > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: OS X ? Such a problem has already bee posted today. I have no access to OS X and thus can't help much. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 17:45:45 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 17:45:45 +0100 Subject: With the release of modern, is there intent to support ECC in classic? In-Reply-To: (Avi's message of "Thu, 6 Nov 2014 10:15:07 -0500") References: Message-ID: <87oaskgtvq.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 16:15, avi.wiki at gmail.com said: > I know that this has been discussed previously, but now that GnuPG modern > has been released with ECC support, is there the intention to add that > support to the classic build in the near-to-internediate future? No. It would be too hard. In case your problem is the pinentry: The agent now provides a loopback pinentry option which basically brings back the version 1 Pinentry prompts. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 17:49:59 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 17:49:59 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <13818.1415282499@sandelman.ca> (Michael Richardson's message of "Thu, 06 Nov 2014 09:01:39 -0500") References: <87ioisn1mo.fsf@vigenere.g10code.de> <13818.1415282499@sandelman.ca> Message-ID: <87fvdwgtoo.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 15:01, mcr at sandelman.ca said: > Werner Koch wrote: > > - All support for PGP-2 keys has been removed for security reasons. > > Does this mean that documents signed decades ago with PGP2 can no longer > be verified? Right. It is anyway useless because you have to assume that such signatures are broken. If you want to decrypt you should have 1.4 versions somewhere. See the whats-new-in-2.1 article: 1.2 Removal of PGP-2 support ???????????????????????????? Some algorithms and parts of the protocols as used by the 20 years old [PGP-2] software are meanwhile considered unsafe. In particular the baked in use of the [MD5] hash algorithm limits the security of PGP-2 keys to non-acceptable rate. Technically those PGP-2 keys are called version 3 keys (v3) and are easily identified by a shorter fingerprint which is commonly presented as 16 separate double hex digits. With GnuPG 2.1 all support for those keys has gone. If they are in an existing keyring they will eventually be removed. If GnuPG encounters such a key on import it will not be imported due to the not anymore implemented v3 key format. Removing the v3 key support also reduces complexity of the code and is thus better than to keep on handling them with a specific error message. There is one use case where PGP-2 keys may still be required: For existing encrypted data. We suggest to keep a version of GnuPG 1.4 around which still has support for these keys (it might be required to use the `--allow-weak-digest-algos' option). A better solution is to re-encrypt the data using a modern key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Nov 6 17:52:53 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 6 Nov 2014 17:52:53 +0100 Subject: key length/size RSA discussion/recommendations in the wiki In-Reply-To: <5453C6F1.8080208@sixdemonbag.org> References: <201410291657.24769.bernhard@intevation.de> <201410311519.28469.bernhard@intevation.de> <5453C6F1.8080208@sixdemonbag.org> Message-ID: <201411061752.54642.bernhard@intevation.de> On Friday 31 October 2014 at 18:29:21, Robert J. Hansen wrote: > I agree that the FAQ is a bad place to present a chain of arguments and > the wiki is the natural spot for it. ?My concern is that the FAQ and the > wiki need to be kept in sync somehow, and I'm not going to be watching > the wiki constantly to make sure we're giving consistent advice. You could register to set a watch email for this page in particular. This way you would at least get some notification (which you would be able to ignore in most cases). MoinMoin allows you do this this in your personal settings. > My other concern is the false air of authority that wikis tend to get. > When anyone can edit, wikis periodically wind up saying ... anything. > If people are looking for a curated line of reasoning from > cryptographers and/or cryptographic engineers, that may not be a good > candidate for a wiki. Yes, I agree about this risk. The other risk is that people are underinformed about GnuPG. Most people know these days that Wikis are written by the people. On the other hand at least I am watching stuff and we could think about moderation in the wiki or other methods. Wikipedia has solved the quality problem, so it is possible. > All this said, though: how can I help? I'd be grateful if you could read through the LargeKeys page and point out obvious obmissions or things that need improvement. You can email me or just try to correct them yourself. (Use you bugs.gnupg.org credentials.) Thanks, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.email Thu Nov 6 18:12:19 2014 From: dougb at dougbarton.email (Doug Barton) Date: Thu, 06 Nov 2014 09:12:19 -0800 Subject: 2.1 vs. multiple keyrings? Message-ID: <545BABF3.7050603@dougbarton.email> At one point in the past there was discussion about 2.1 only allowing one public keyring, but I don't see anything about that in the "What's new" doc. Can I safely assume that 2.1 has support for multiple keyrings in the same gpg.conf and/or command line? Doug From mailing-lists at asatiifm.net Thu Nov 6 18:13:00 2014 From: mailing-lists at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Thu, 6 Nov 2014 19:13:00 +0200 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87k338gtrt.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87k338gtrt.fsf@vigenere.g10code.de> Message-ID: <87762265-FC9D-44AD-A196-AC439A4F4B23@asatiifm.net> Yeah, OS X. I?m sorry, I?m sure this is drowning to all the discussion on this thread, I didn?t think too much about the subject. I was replying to Nicholas? reported issues with building on OS X. My aim was to expand on Nicholas? report with the info that it?s failing with that error yes, but before that it?s failing linking to version 0.13 of libgpg_error whereas I have 0.16 and 0.17 available. As I see it this feels like a ./configure fail on the dependency. -- Ville On 6 Nov 2014, at 18:48, Werner Koch wrote: > On Thu, 6 Nov 2014 15:14, mailing-lists at asatiifm.net said: > >> Undefined symbols for architecture x86_64: >> "_default_errsource", referenced from: > > OS X ? > > Such a problem has already bee posted today. I have no access to OS X > and thus can't help much. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From avi.wiki at gmail.com Thu Nov 6 18:17:15 2014 From: avi.wiki at gmail.com (Avi) Date: Thu, 6 Nov 2014 12:17:15 -0500 Subject: With the release of modern, is there intent to support ECC in classic? In-Reply-To: <87oaskgtvq.fsf@vigenere.g10code.de> References: <87oaskgtvq.fsf@vigenere.g10code.de> Message-ID: Understood, Werner and Rob, thank you for the clarification. I'll try to install a minimal version of GnuPG 2.1 and see how that works. As always, the work of the GnuPG developers, maintainers, and supporters is greatly appreciated! Avi ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 On Thu, Nov 6, 2014 at 11:45 AM, Werner Koch wrote: > On Thu, 6 Nov 2014 16:15, avi.wiki at gmail.com said: > > > I know that this has been discussed previously, but now that GnuPG modern > > has been released with ECC support, is there the intention to add that > > support to the classic build in the near-to-internediate future? > > No. It would be too hard. In case your problem is the pinentry: The > agent now provides a loopback pinentry option which basically brings > back the version 1 Pinentry prompts. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Thu Nov 6 18:51:38 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 06 Nov 2014 18:51:38 +0100 Subject: With the release of modern, is there intent to support ECC in classic? In-Reply-To: <87oaskgtvq.fsf@vigenere.g10code.de> References: <87oaskgtvq.fsf@vigenere.g10code.de> Message-ID: <545BB52A.8010101@digitalbrains.com> On 06/11/14 17:45, Werner Koch wrote: > In case your problem is the pinentry: The agent now provides a > loopback pinentry option which basically brings back the version 1 > Pinentry prompts. Perhaps this warrants a mention on the what's new FAQ page, for people that are using 1.4 for that specific reason. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Thu Nov 6 19:26:24 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 19:26:24 +0100 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545BA68D.9020303@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 06 Nov 2014 11:49:17 -0500") References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> <545B9F07.40705@fifthhorseman.net> <545BA68D.9020303@sixdemonbag.org> Message-ID: <878ujogp7z.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 17:49, rjh at sixdemonbag.org said: > compels me to say that I'm running into a *lot* of problems with the > Windows build. It does not appear to me to be ready for prime time. That is why I wrote "is an experimental installer" ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 6 19:28:53 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 06 Nov 2014 19:28:53 +0100 Subject: 2.1 vs. multiple keyrings? In-Reply-To: <545BABF3.7050603@dougbarton.email> (Doug Barton's message of "Thu, 06 Nov 2014 09:12:19 -0800") References: <545BABF3.7050603@dougbarton.email> Message-ID: <874mucgp3u.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 18:12, dougb at dougbarton.email said: > one public keyring, but I don't see anything about that in the "What's > new" doc. Can I safely assume that 2.1 has support for multiple > keyrings in the same gpg.conf and/or command line? Yes, it should work. However, there are no test cases and I would recommend against using more than one keyring. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dougb at dougbarton.email Thu Nov 6 19:32:22 2014 From: dougb at dougbarton.email (Doug Barton) Date: Thu, 06 Nov 2014 10:32:22 -0800 Subject: 2.1 vs. multiple keyrings? In-Reply-To: <874mucgp3u.fsf@vigenere.g10code.de> References: <545BABF3.7050603@dougbarton.email> <874mucgp3u.fsf@vigenere.g10code.de> Message-ID: <545BBEB6.50003@dougbarton.email> On 11/6/14 10:28 AM, Werner Koch wrote: > On Thu, 6 Nov 2014 18:12, dougb at dougbarton.email said: > >> one public keyring, but I don't see anything about that in the "What's >> new" doc. Can I safely assume that 2.1 has support for multiple >> keyrings in the same gpg.conf and/or command line? > > Yes, it should work. However, there are no test cases and I would > recommend against using more than one keyring. Thanks for the response. :) I will test it when I can and report back. Doug From rjh at sixdemonbag.org Thu Nov 6 20:09:15 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 14:09:15 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <878ujogp7z.fsf@vigenere.g10code.de> References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> <545B9F07.40705@fifthhorseman.net> <545BA68D.9020303@sixdemonbag.org> <878ujogp7z.fsf@vigenere.g10code.de> Message-ID: <545BC75B.3010005@sixdemonbag.org> > That is why I wrote "is an experimental installer" ;-) Sure, but even then -- this is a really shaky build, Werner. I'm getting all different kinds of weird errors, from the keyserver helper not being able to communicate with the outside world, to GnuPG swearing it's created output but no output file being created (!!), to GnuPG 2.1.0 + Enigmail inserting additional newlines after every line of text, to GnuPG 2.1.0 + Enigmail telling me it's successfully decrypted a message but presenting me with a blank screen, to... Some of this is probably on Enigmail; some of it is probably on Win32. My own recommendation, for whatever it's worth, is that normal Win32 users should *not* upgrade. Not yet, at least. There's a lot of stuff here that needs shaking out. (The "GnuPG insists it's created output, but none exists" -- this one was so surreal that I was seriously considering whether I was hallucinating from caffeine withdrawal, as I'd skipped my morning cup. I cd'ed into the C:\Program Files (x86)\Gnu\GnuPG\bin directory, so as to avoid having to type "gpg.exe" each time. I wanted to test encrypting a file on my desktop, and I could've sworn I set the output to C:\Users\rjh\Desktop. I didn't, though, and GnuPG dumped the output into the C:\Program Files (x86)\GNU\GnuPG\bin directory... ... or at least, it claimed to. When I did a dir on the directory, the output didn't exist. "Hmm," I thought, "that's weird. Did it not have permissions to write to the dir? If so, shouldn't it have given an error?" So I repeated the same command line. This time, GnuPG told me the file foo.asc already existed, and did I want to overwrite it? I Ctrl-Ced out. Intrigued, I combed through the directory looking for foo.asc. It wasn't there. So what the heck was GnuPG warning me about overwriting? At some point I had to seriously consider the possibility I was hallucinating it. I'm pretty sure I wasn't. But I can't explain for the life of me what happened there.) From bighype at gmail.com Thu Nov 6 19:37:11 2014 From: bighype at gmail.com (Mel Brands) Date: Thu, 6 Nov 2014 13:37:11 -0500 Subject: Error building GnuPG modern 2.1.0 on Yosemite Message-ID: Hi guys, I tried to compile 2.1.0 today and ran into an issue. I have the latest autoconf/m4/gnu toolchain and all of the latest libraries that GnuPG needs. ./confgure output looks OK to me and it has no complaints. You can see the full output here: http://pastebin.com/YvTtXMed But after I run make, it fails like this: ----------------------- gnupg-2.1.0 $ make make all-recursive Making all in m4 make[2]: Nothing to be done for `all'. Making all in gl { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ cat ./alloca_.h; \ } > alloca.h-t mv -f alloca.h-t alloca.h rm -f stdint.h-t stdint.h { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ sed -e 's/@''HAVE_WCHAR_H''@/1/g' \ -e 's/@''HAVE_STDINT_H''@/1/g' \ -e 's|@''ABSOLUTE_STDINT_H''@|"///usr/include/stdint.h"|g' \ -e 's/@''HAVE_SYS_TYPES_H''@/1/g' \ -e 's/@''HAVE_INTTYPES_H''@/1/g' \ -e 's/@''HAVE_SYS_INTTYPES_H''@/0/g' \ -e 's/@''HAVE_SYS_BITYPES_H''@/0/g' \ -e 's/@''HAVE_LONG_LONG_INT''@/1/g' \ -e 's/@''HAVE_UNSIGNED_LONG_LONG_INT''@/1/g' \ -e 's/@''BITSIZEOF_PTRDIFF_T''@/64/g' \ -e 's/@''PTRDIFF_T_SUFFIX''@/l/g' \ -e 's/@''BITSIZEOF_SIG_ATOMIC_T''@/32/g' \ -e 's/@''HAVE_SIGNED_SIG_ATOMIC_T''@/1/g' \ -e 's/@''SIG_ATOMIC_T_SUFFIX''@//g' \ -e 's/@''BITSIZEOF_SIZE_T''@/64/g' \ -e 's/@''SIZE_T_SUFFIX''@/ul/g' \ -e 's/@''BITSIZEOF_WCHAR_T''@/32/g' \ -e 's/@''HAVE_SIGNED_WCHAR_T''@/1/g' \ -e 's/@''WCHAR_T_SUFFIX''@//g' \ -e 's/@''BITSIZEOF_WINT_T''@/32/g' \ -e 's/@''HAVE_SIGNED_WINT_T''@/1/g' \ -e 's/@''WINT_T_SUFFIX''@//g' \ < ./stdint_.h; \ } > stdint.h-t mv stdint.h-t stdint.h make all-am gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT allocsa.o -MD -MP -MF .deps/allocsa.Tpo -c -o allocsa.o allocsa.c mv -f .deps/allocsa.Tpo .deps/allocsa.Po rm -f libgnu.a ar cru libgnu.a allocsa.o ranlib libgnu.a Making all in common make all-am gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\"" -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DWITHOUT_NPTH=1 -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT libcommon_a-mapstrings.o -MD -MP -MF .deps/libcommon_a-mapstrings.Tpo -c -o libcommon_a-mapstrings.o `test -f 'mapstrings.c' || echo './'`mapstrings.c In file included from /usr/include/inttypes.h:247, from ../common/types.h:35, from ../common/argparse.h:35, from util.h:44, from mapstrings.c:34: ../gl/stdint.h:62:31: error: _types/_intmax_t.h: No such file or directory ../gl/stdint.h:63:32: error: _types/_uintmax_t.h: No such file or directory make[3]: *** [libcommon_a-mapstrings.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ----------------------- What am I doing wrong? Any hints/insight much appreciated! Thank you! Mel From rjh at sixdemonbag.org Thu Nov 6 20:58:45 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 14:58:45 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <545BD2F5.4070105@sixdemonbag.org> > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. Is there any guidance as to how to install this on Fedora 20? gnupg2 is a protected package there: it literally cannot be removed without completely breaking the system. (The cause of the total-breakage: yum, the Fedora package manager, has gnupg2 as a dependency.) The timing of GnuPG 2.1 is a little unfortunate: we're already past the beta freeze and final freeze is coming up in just a few days. It's unlikely GnuPG 2.1 will make it into Fedora 21, and I doubt Fedora will shift from 2.0 to 2.1 outside of a major release, meaning Fedora users will be left using 2.0 for six months or so. In the grand scheme of things this is an annoyance more than anything else... but still, an annoyance. :) From mcr at sandelman.ca Thu Nov 6 15:01:39 2014 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 06 Nov 2014 09:01:39 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <13818.1415282499@sandelman.ca> Werner Koch wrote: > - All support for PGP-2 keys has been removed for security reasons. Does this mean that documents signed decades ago with PGP2 can no longer be verified? If so, I guess this is a reason to keep GPG classic around for verification purposes only. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available URL: From mcr at sandelman.ca Thu Nov 6 20:05:04 2014 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 06 Nov 2014 14:05:04 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87fvdwgtoo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <13818.1415282499@sandelman.ca> <87fvdwgtoo.fsf@vigenere.g10code.de> Message-ID: <11334.1415300704@sandelman.ca> Werner Koch wrote: >> Werner Koch wrote: > - All support for PGP-2 keys has >> been removed for security reasons. >> >> Does this mean that documents signed decades ago with PGP2 can no >> longer be verified? > Right. It is anyway useless because you have to assume that such > signatures are broken. If you want to decrypt you should have 1.4 I agree that one's confidence in that content should be suspect, but the value is not zero. I am happy that you have removed the support, btw. Simpler code is important. > There is one use case where PGP-2 keys may still be required: For > existing encrypted data. We suggest to keep a version of GnuPG 1.4 > around which still has support for these keys (it might be required to > use the `--allow-weak-digest-algos' option). A better solution is to > re-encrypt the data using a modern key. Yes, that was idea too -- just use 1.4. And one can't re-encrypt data signed by another. In many cases, in my archives, I have email that is clear signed, which was then encrypted, and stored that way. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu Nov 6 21:39:14 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 06 Nov 2014 15:39:14 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545BC75B.3010005@sixdemonbag.org> References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> <545B9F07.40705@fifthhorseman.net> <545BA68D.9020303@sixdemonbag.org> <878ujogp7z.fsf@vigenere.g10code.de> <545BC75B.3010005@sixdemonbag.org> Message-ID: <545BDC72.4020607@sixdemonbag.org> > Some of this is probably on Enigmail; some of it is probably on Win32. Ack -- I meant some of it is probably on GnuPG/Win32. :) From kristian.fiskerstrand at sumptuouscapital.com Fri Nov 7 03:24:43 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 07 Nov 2014 03:24:43 +0100 Subject: gpg-agent forwarding In-Reply-To: <545B8F0D.3040901@digitalbrains.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> <545B76C1.4090608@digitalbrains.com> <87k338jstt.fsf@vigenere.g10code.de> <545B8F0D.3040901@digitalbrains.com> Message-ID: <545C2D6B.8020202@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/06/2014 04:09 PM, Peter Lebbing wrote: > On 06/11/14 15:40, Werner Koch wrote: >> OpenSSH has socket forwarding and that is what I was thinking >> about. > > Sockets other than TCP you mean? Is this something generic that can > be invoked by using the command-line OpenSSH client? I can't find > it. > See https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028697.html - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Ad astra per aspera To the stars through thorns -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUXC1pAAoJEPw7F94F4TagBekP/3k3ORtAj+/KVHsc2SOAlmpj Xf3JMhKiHRi9p9mbXQkQ4Kj5BpTrN2Eh8/MgUgnB1dI1wSA7FvwMx5UcyuAIhKVP hxESj0x6YcuUwk8pZPqkcII39Qwz1ifjovdrmrfQraM+GbLyvD1SpYrqSCH53gvH xecoGBIve2/sanorpSR3bbeUsaZ7J3clnlhfTaCaL6WrBkflTcsa2cEXdS7MVImN b3emvfe5M3yFPT7LtSg4Z85+7jdHj6IrBFL5tEy8d+SlC8jWczWWyvSdOgbbqt8e VBjpuB+0ZHNGc3rzOqaqRu+Lk5eVnuChmg4kSaq8VEvL5XV3FUuiHfe0/XnAX56e tj0rdveL+Ip2QGT4oUJKAwQlwb3+EenlhyVo1KjXGE9224t/YgXWC2KL3PsEfiFv 12NGFncZIiKntxCxFfK15qIuAsF3irX/96nVDLeUdP8/mfZYNl2iGIwHrAZn9YWc cZZgFVMWBPsSgiYferjQnTuSSIqqBtp3KPQItEU5tEKdYlXQG5Na+REyws0A7p8l iOZI2sSTeF2oi2WAHHyrBwa4+0tjb4mXRyxMi+X3luszZ8ctcl18LyUr1hn/Am3m l41VtPQYpnie7EhIxLQLz4lF8J+lFBuBGA/Pzfo78HOQZWnlV6+ROw/iOvUsQcny VhYhAvV+P+aeUgN6lSuX =jVxi -----END PGP SIGNATURE----- From wk at gnupg.org Fri Nov 7 07:44:40 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 07:44:40 +0100 Subject: Error building GnuPG modern 2.1.0 on Yosemite In-Reply-To: (Mel Brands's message of "Thu, 6 Nov 2014 13:37:11 -0500") References: Message-ID: <87lhnnfr1j.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 19:37, bighype at gmail.com said: > I tried to compile 2.1.0 today and ran into an issue. I have the > latest autoconf/m4/gnu toolchain and all of the latest libraries that > GnuPG needs. It is kind of funny that GnuPG as most autoconf enabled programs build fine on so many Unix platform but not on OS X we should be a modern Unix. One of the reasons might be that GnuPG uses a small part of gnulib (gl/) but does not follow all the gnulib updates to avoid regressions. > ../gl/stdint.h:62:31: error: _types/_intmax_t.h: No such file or directory > ../gl/stdint.h:63:32: error: _types/_uintmax_t.h: No such file or directory This problem seems to cause by the hack below. We hoped that this would fix the problems but obviously it didn't on all machines. You may try to revert that patch. For 2.0.1 I'd really like to get access to a decent OS X box to test the build before releasing it. Salam-Shalom, Werner commit f5592fcff308007322a201c970a6d5e8763c9fe3 Author: Werner Koch Date: Wed Oct 29 15:41:28 2014 +0100 Fix stdint.h problem for Apple. * gl/stdint_.h [__APPLE__]: Include hack. -- Patch suggested by Patrick Brunschwig. Modified gl/stdint_.h diff --git a/gl/stdint_.h b/gl/stdint_.h index 19577e7..1118e8d 100644 --- a/gl/stdint_.h +++ b/gl/stdint_.h @@ -55,6 +55,13 @@ # include @ABSOLUTE_STDINT_H@ #endif +#ifdef __APPLE__ + /* Apple's implementation of is bugy; we therefore use + the source definitions. */ +# include <_types/_intmax_t.h> +# include <_types/_uintmax_t.h> +#endif + /* defines some of the stdint.h types as well, on glibc, IRIX 6.5, and OpenBSD 3.8 (via ). MacOS X 10.4.6 includes (which is us), but -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 7 10:28:37 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 10:28:37 +0100 Subject: gpg-agent forwarding In-Reply-To: <545B8F0D.3040901@digitalbrains.com> (Peter Lebbing's message of "Thu, 06 Nov 2014 16:09:01 +0100") References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> <545B76C1.4090608@digitalbrains.com> <87k338jstt.fsf@vigenere.g10code.de> <545B8F0D.3040901@digitalbrains.com> Message-ID: <87d28zfjga.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 16:09, peter at digitalbrains.com said: > is obviously not needed. Were you thinking of writing that functionality > for OpenSSH on Linux as well? Not required. I was thinking of extending the Putty client site. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 7 10:26:33 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 10:26:33 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <545BD2F5.4070105@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 06 Nov 2014 14:58:45 -0500") References: <87ioisn1mo.fsf@vigenere.g10code.de> <545BD2F5.4070105@sixdemonbag.org> Message-ID: <87h9ybfjjq.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 20:58, rjh at sixdemonbag.org said: > Is there any guidance as to how to install this on Fedora 20? gnupg2 is Does the method I proposed on wiki.gnupg.org work for you? that is installing it in the HOME directory with PATH and LD_LIBRARY_PATH set accordingly? > The timing of GnuPG 2.1 is a little unfortunate: we're already past the > beta freeze and final freeze is coming up in just a few days. It's Dame as with Debian. However the Debian folks are still working on installing 2.0 by default. > shift from 2.0 to 2.1 outside of a major release, meaning Fedora users > will be left using 2.0 for six months or so. Well, that is early when thinking in Debian time spans ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nan at goodcrypto.com Fri Nov 7 11:21:11 2014 From: nan at goodcrypto.com (Nan) Date: Fri, 7 Nov 2014 10:21:11 GMT Subject: Tweeting for GnuPG Message-ID: <20141107102111MuDTyKFugo@goodcrypto.com> Werner, depending on what you want, we might be able to help. Here are some kinds of tweets that might be good for gpg: * Links to mentions of gpg, and maybe pgp * Links to mentions of attacks when we can say "This wouldn't have happened with GPG would have stopped/resisted this." * News about gpg from you and maybe products that use it Obviously that last category would include us, and you may not want to include community product news. How often is "regular"? rob at aspman.info is probably a better choice than me since I find Twitter a pain. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From yesmar at icloud.com Fri Nov 7 06:41:41 2014 From: yesmar at icloud.com (Ramsey Dow) Date: Thu, 06 Nov 2014 21:41:41 -0800 Subject: Problem compiling GnuPG 2.1.0 on OS X 10.10 Message-ID: <9D90696B-3792-4B64-90D2-09BD02E8010F@icloud.com> Hello, I am having a build failure with GnuPG 2.1.0 on OS X 10.10 using Xcode 6.1's compiler tools. I have successfully compiled and installed all of the prerequisite libraries (npth 1.1, libgpg-error 1.17, libksba 1.3.1, and libassuan 2.1.2). My build sequence is as follows: gpg --verify $MRT/cache/gnupg-2.1.0.tar.bz2.sig tar xjf $MRT/cache/gnupg-2.1.0.tar.bz2 pushd gnupg-2.1.0 ./configure --prefix=$MRTRT make The compilation fails while linking t-sexputil in common. Here are the last few lines of the build process: gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -DLOCALEDIR=\"/Users/ramsey/Developer/MRT/runtime/share/locale\" -DGNUPG_BINDIR="\"/Users/ramsey/Developer/MRT/runtime/bin\"" -DGNUPG_LIBEXECDIR="\"/Users/ramsey/Developer/MRT/runtime/libexec\"" -DGNUPG_LIBDIR="\"/Users/ramsey/Developer/MRT/runtime/lib/gnupg\"" -DGNUPG_DATADIR="\"/Users/ramsey/Developer/MRT/runtime/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/Users/ramsey/Developer/MRT/runtime/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/Users/ramsey/Developer/MRT/runtime/var\"" -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT t-sexputil.o -MD -MP -MF .deps/t-sexputil.Tpo -c -o t-sexputil.o t-sexputil.c mv -f .deps/t-sexputil.Tpo .deps/t-sexputil.Po gcc -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/Users/ramsey/Developer/MRT/runtime/lib -lgcrypt -lgpg-error -lassuan -L/Users/ramsey/Developer/MRT/runtime/lib -lgpg-error -L/Users/ramsey/Developer/MRT/runtime/lib -lgpg-error -liconv Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [t-sexputil] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I'm not sure why this error is occurring, which is why I am reporting it here, per instructions in the README. Am I forgetting to specify an option to configure? Is the configuration subsystem missing something about my system's setup? Please advise. I'm happy to provide any other details if necessary. Thanks, Ramsey ? #define true (rand() > 10) /* happy debugging, suckers */ From peter at digitalbrains.com Fri Nov 7 12:09:16 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 07 Nov 2014 12:09:16 +0100 Subject: gpg-agent forwarding In-Reply-To: <545C2D6B.8020202@sumptuouscapital.com> References: <91f10d387d4b4d25b8432dfb870e111e@hioexcmbx04-prd.hq.netapp.com> <5453F975.7040205@fifthhorseman.net> <6088cc41b8114f6284eab1cf50a640e9@hioexcmbx04-prd.hq.netapp.com> <54591650.1040902@fifthhorseman.net> <02c7c6252e5b427cab68700d7ef7263d@hioexcmbx04-prd.hq.netapp.com> <685f91ac082341518c98077ee9504d9a@hioexcmbx04-prd.hq.netapp.com> <545A846E.90206@digitalbrains.com> <87zjc5mk0q.fsf@vigenere.g10code.de> <545B76C1.4090608@digitalbrains.com> <87k338jstt.fsf@vigenere.g10code.de> <545B8F0D.3040901@digitalbrains.com> <545C2D6B.8020202@sumptuouscapital.com> Message-ID: <545CA85C.2010809@digitalbrains.com> On 07/11/14 03:24, Kristian Fiskerstrand wrote: > See https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028697.html Right, thanks for the pointer! Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From nan at goodcrypto.com Fri Nov 7 12:38:36 2014 From: nan at goodcrypto.com (Nan) Date: Fri, 7 Nov 2014 11:38:36 GMT Subject: GPG API: Open Crypto Engine Message-ID: <20141107113836hzRDhd8N8b@goodcrypto.com> If you want to use gpg in an app, there's an easy way. The Open Crypto Engine is one API for multiple crypto plugins. Open source. We've released a Python version with a gpg plugin at https://gibhub.com/goodcrypto/. There's also a java version with more plugins. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From mustrum at mustrum.net Fri Nov 7 09:13:33 2014 From: mustrum at mustrum.net (Mustrum) Date: Fri, 07 Nov 2014 09:13:33 +0100 Subject: GnuPG 2.1 pinentry copy/paste on windows system Message-ID: <73560B94-EB48-4077-B7E8-D6B0A3FAF3DF@mustrum.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 If you need to be able to past your 'very strong passphrase' (may be from keepass) you can use the old pinentry provided with gpg4win 2.2, without install it. Open the installer with 7z and copy all the dll and pinentry exec onto a new ditectory. Edit your gpg-agent.conf to add the option: Pinentry-program "your own pinentry full path" Restart your gpg-agent.. Works on my xp and win7.. Regards. -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI7BAEBCgAlBQJUXH8tHhxNdXN0cnVtIDxNdXN0cnVtQE11c3RydW0ubmV0PgAK CRBMuv2GX9WDni7eEADDmoKx5y0x6SavYJ79Bw7uCDH49js01W19WVwocaHW042d oCZRbdcgIQSfzEqCdVggm+V5CMhyxqYotxKxKSn2Vq3fLXyxfB8DMP465PsDqFma 6PslQrlE2rulW1mkwj3mLMo/08q9GRebQJK/Dha9wAEz9uouEDP3rCaCYuJ6rp5R LzIc4jM1BQoJHDTP32XIwbGBkBPjJgrBU2LhxHgveiN1M2wMFfWY7P7YOsUoRV95 FLzcXpaImmNsMyTFTatgnwgn3ALDDWhX7FQoK/irTmxsOxGFVdk0M9crczY6Gf0v uzW3vaw9r6TeiX4VkOiwTzafGrAYioZvf3ooyA9z/5tvoSiG7HHuJ6m1c+aIt7R/ vLnpq8CMKOeu0wAYLdOlC3Ql5fsL0aiQDAhU7d9hqEzzEUwfUeRoe+0PA2dH6uOr xWQ0rEgb5FofzVnqIJDZSoWjtnNkhrXBl+UtHVLCNWl+Q3Nr3D68qyn4qH4a2+a0 FPG2DxJyBABtFn7um8cYs146jB76/GjL149Szs0jKVwvE5GxhWTHCFtqUvBazelu PVzWrphyIlAOO9N9u3ujGNuXVwPjyPqZzcjWkxCzqajNiCWVWGF4Q4tutRMmrLqY PjGlmt2Rp3dkgX10epJfgIPqrgjltFqmC707IKr10Y+9kbfpecaR12OKNt04qA== =bT3x -----END PGP SIGNATURE----- From wk at gnupg.org Fri Nov 7 17:23:48 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 17:23:48 +0100 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9AA7.2070603@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 06 Nov 2014 10:58:31 -0500") References: <545B9AA7.2070603@sixdemonbag.org> Message-ID: <87ppczdlnu.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 16:58, rjh at sixdemonbag.org said: > C:\utils>gpg --keyserver pool.sks-keyservers.net --recv-key d5078b4f > gpg: keyserver receive failed: Input/output error Well, you caught me. I only tested GPA and knowing that its keyserver access does not yet work I probably did no tests at all. Meanwhile I found the problem and keyserver access does work again. (Not yet commited). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 7 17:32:49 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 17:32:49 +0100 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545BC75B.3010005@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 06 Nov 2014 14:09:15 -0500") References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> <545B9F07.40705@fifthhorseman.net> <545BA68D.9020303@sixdemonbag.org> <878ujogp7z.fsf@vigenere.g10code.de> <545BC75B.3010005@sixdemonbag.org> Message-ID: <87lhnndl8u.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 20:09, rjh at sixdemonbag.org said: > getting all different kinds of weird errors, from the keyserver helper > not being able to communicate with the outside world, to GnuPG Well, there are no more keyserver helpers. All is done by dirmngr. > swearing it's created output but no output file being created (!!), to Hmmm, I can't see that. > (The "GnuPG insists it's created output, but none exists" -- this one > was so surreal that I was seriously considering whether I was Sorry, I can't replicate that. Well, with the fixed version but I didn't touched anything relevant in gpg.exe. > So I repeated the same command line. This time, GnuPG told me the > file foo.asc already existed, and did I want to overwrite it? Is that some weird Windows symlink setup? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 7 17:39:01 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 17:39:01 +0100 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: <545B9DD4.3020500@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 06 Nov 2014 11:12:04 -0500") References: <545B9AA7.2070603@sixdemonbag.org> <545B9DD4.3020500@sixdemonbag.org> Message-ID: <878ujndkyi.fsf@vigenere.g10code.de> On Thu, 6 Nov 2014 17:12, rjh at sixdemonbag.org said: > Next round of problems: doing a --list-secret-keys takes considerable > time -- approximately 28 seconds on a fairly modern > desktop. --list-keys, though, is pretty snappy. Found. The I/O layer received many EAGAIN (WSAEWOULDBLOCK). Basically always after switching from writing to reading. On EGAIN libassuan introduces a 100ms delay before retrying - that sums up to the slow listing (which requires IPC with the gpg-agent). EGAIN should be seen only rarely and thus the 100ms delay is a good solution. However it seems that Windows (7/64bit here, but the years before I developed on XP) handles local TCP connections now in a different way. The solution is to select after an EAGAIN and retry. This really speeds up things. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Nov 7 17:44:49 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 07 Nov 2014 17:44:49 +0100 Subject: GnuPG 2.1 pinentry copy/paste on windows system In-Reply-To: <73560B94-EB48-4077-B7E8-D6B0A3FAF3DF@mustrum.net> (mustrum@mustrum.net's message of "Fri, 07 Nov 2014 09:13:33 +0100") References: <73560B94-EB48-4077-B7E8-D6B0A3FAF3DF@mustrum.net> Message-ID: <874mubdkou.fsf@vigenere.g10code.de> Hi, actually the delivered pinentry should be able to do that. It works on Unix but I just figured that it does not work on Windows. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Fri Nov 7 19:53:35 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 07 Nov 2014 13:53:35 -0500 Subject: Clang with GnuPG 2.1.0 Message-ID: <545D152F.3040806@sixdemonbag.org> A great way to find hidden GNUisms is to use a non-GNU compiler, which is why I generally prefer to compile things with Clang -- it's a nice sanity check on code. GnuPG 2.1.0 is refusing to build on a freshly-updated Fedora 20 box using Clang 3.4. (It compiles just fine with GCC, incidentally.) ===== make[3]: Entering directory `/home/rjh/gnupg-2.1.0/common' clang -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -DLOCALEDIR=\"/home/rjh/share/locale\" -DGNUPG_BINDIR="\"/home/rjh/bin\"" -DGNUPG_LIBEXECDIR="\"/home/rjh/libexec\"" -DGNUPG_LIBDIR="\"/home/rjh/lib/gnupg\"" -DGNUPG_DATADIR="\"/home/rjh/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/home/rjh/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/home/rjh/var\"" -I/home/rjh/include -I/home/rjh/include -I/home/rjh/include -I/home/rjh/include -DWITHOUT_NPTH=1 -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT libcommon_a-logging.o -MD -MP -MF .deps/libcommon_a-logging.Tpo -c -o libcommon_a-logging.o `test -f 'logging.c' || echo './'`logging.c In file included from logging.c:51: In file included from /usr/include/netinet/in.h:22: In file included from ../gl/stdint.h:83: /usr/include/inttypes.h:290:8: error: unknown type name 'intmax_t' extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__)); ^ /usr/include/inttypes.h:290:26: error: unknown type name 'intmax_t' extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__)); ^ /usr/include/inttypes.h:293:27: error: unknown type name 'intmax_t' extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom) ^ /usr/include/inttypes.h:293:45: error: unknown type name 'intmax_t' extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom) ^ /usr/include/inttypes.h:297:8: error: unknown type name 'intmax_t' extern intmax_t strtoimax (const char *__restrict __nptr, ^ /usr/include/inttypes.h:301:8: error: unknown type name 'uintmax_t' extern uintmax_t strtoumax (const char *__restrict __nptr, ^ /usr/include/inttypes.h:305:8: error: unknown type name 'intmax_t' extern intmax_t wcstoimax (const __gwchar_t *__restrict __nptr, ^ /usr/include/inttypes.h:310:8: error: unknown type name 'uintmax_t' extern uintmax_t wcstoumax (const __gwchar_t *__restrict __nptr, ^ /usr/include/inttypes.h:323:17: error: unknown type name 'intmax_t' __extern_inline intmax_t ^ /usr/include/inttypes.h:324:1: error: expected identifier or '(' __NTH (strtoimax (const char *__restrict nptr, char **__restrict endptr, ^ /usr/include/sys/cdefs.h:57:22: note: expanded from macro '__NTH' # define __NTH(fct) __attribute__ ((__nothrow__ __LEAF)) fct ^ In file included from logging.c:51: In file included from /usr/include/netinet/in.h:22: In file included from ../gl/stdint.h:83: /usr/include/inttypes.h:335:17: error: unknown type name 'uintmax_t' __extern_inline uintmax_t ^ /usr/include/inttypes.h:336:1: error: expected identifier or '(' __NTH (strtoumax (const char *__restrict nptr, char **__restrict endptr, ^ /usr/include/sys/cdefs.h:57:22: note: expanded from macro '__NTH' # define __NTH(fct) __attribute__ ((__nothrow__ __LEAF)) fct ^ In file included from logging.c:51: In file included from /usr/include/netinet/in.h:22: In file included from ../gl/stdint.h:83: /usr/include/inttypes.h:347:17: error: unknown type name 'intmax_t' __extern_inline intmax_t ^ /usr/include/inttypes.h:348:1: error: expected identifier or '(' __NTH (wcstoimax (const __gwchar_t *__restrict nptr, ^ /usr/include/sys/cdefs.h:57:22: note: expanded from macro '__NTH' # define __NTH(fct) __attribute__ ((__nothrow__ __LEAF)) fct ^ In file included from logging.c:51: In file included from /usr/include/netinet/in.h:22: In file included from ../gl/stdint.h:83: /usr/include/inttypes.h:361:17: error: unknown type name 'uintmax_t' __extern_inline uintmax_t ^ /usr/include/inttypes.h:362:1: error: expected identifier or '(' __NTH (wcstoumax (const __gwchar_t *__restrict nptr, ^ /usr/include/sys/cdefs.h:57:22: note: expanded from macro '__NTH' # define __NTH(fct) __attribute__ ((__nothrow__ __LEAF)) fct ^ In file included from logging.c:54: /usr/include/unistd.h:267:20: error: cannot combine with previous 'type-name' declaration specifier typedef __intptr_t intptr_t; ^ ../gl/stdint.h:229:23: note: expanded from macro 'intptr_t' #define intptr_t long int ^ In file included from logging.c:54: /usr/include/unistd.h:267:20: error: 'long type-name' is invalid ../gl/stdint.h:229:18: note: expanded from macro 'intptr_t' #define intptr_t long int ^ 18 errors generated. From patrick at enigmail.net Sat Nov 8 18:10:41 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 08 Nov 2014 18:10:41 +0100 Subject: Error building GnuPG modern 2.1.0 on Yosemite In-Reply-To: <87lhnnfr1j.fsf__43048.0139483281$1415342807$gmane$org@vigenere.g10code.de> References: <87lhnnfr1j.fsf__43048.0139483281$1415342807$gmane$org@vigenere.g10code.de> Message-ID: <545E4E91.4090308@enigmail.net> On 07.11.14 07:44, Werner Koch wrote: > On Thu, 6 Nov 2014 19:37, bighype at gmail.com said: > >> I tried to compile 2.1.0 today and ran into an issue. I have the >> latest autoconf/m4/gnu toolchain and all of the latest libraries that >> GnuPG needs. > > It is kind of funny that GnuPG as most autoconf enabled programs build > fine on so many Unix platform but not on OS X we should be a modern > Unix. > > One of the reasons might be that GnuPG uses a small part of gnulib (gl/) > but does not follow all the gnulib updates to avoid regressions. > >> ../gl/stdint.h:62:31: error: _types/_intmax_t.h: No such file or directory >> ../gl/stdint.h:63:32: error: _types/_uintmax_t.h: No such file or directory > > This problem seems to cause by the hack below. We hoped that this would > fix the problems but obviously it didn't on all machines. You may try > to revert that patch. > > For 2.0.1 I'd really like to get access to a decent OS X box to test the > build before releasing it. I'm currently using Mavericks (10.9) with Xcode 6.1. I can imagine that this is different on Yosemite (10.10) and/or a different version of XCode. :-( Which version of XCode do you (Mel) use? -Patrick From patrick at enigmail.net Sat Nov 8 19:04:19 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 08 Nov 2014 19:04:19 +0100 Subject: Problem compiling GnuPG 2.1.0 on OS X 10.10 In-Reply-To: <9D90696B-3792-4B64-90D2-09BD02E8010F__32846.578237559$1415357996$gmane$org@icloud.com> References: <9D90696B-3792-4B64-90D2-09BD02E8010F__32846.578237559$1415357996$gmane$org@icloud.com> Message-ID: <545E5B23.6040309@enigmail.net> On 07.11.14 06:41, Ramsey Dow wrote: > Hello, I am having a build failure with GnuPG 2.1.0 on OS X 10.10 using Xcode 6.1's compiler tools. > > I have successfully compiled and installed all of the prerequisite libraries (npth 1.1, libgpg-error 1.17, libksba 1.3.1, and libassuan 2.1.2). My build sequence is as follows: > > gpg --verify $MRT/cache/gnupg-2.1.0.tar.bz2.sig > tar xjf $MRT/cache/gnupg-2.1.0.tar.bz2 > pushd gnupg-2.1.0 > ./configure --prefix=$MRTRT > make > > The compilation fails while linking t-sexputil in common. Here are the last few lines of the build process: > > gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -DLOCALEDIR=\"/Users/ramsey/Developer/MRT/runtime/share/locale\" -DGNUPG_BINDIR="\"/Users/ramsey/Developer/MRT/runtime/bin\"" -DGNUPG_LIBEXECDIR="\"/Users/ramsey/Developer/MRT/runtime/libexec\"" -DGNUPG_LIBDIR="\"/Users/ramsey/Developer/MRT/runtime/lib/gnupg\"" -DGNUPG_DATADIR="\"/Users/ramsey/Developer/MRT/runtime/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/Users/ramsey/Developer/MRT/runtime/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/Users/ramsey/Developer/MRT/runtime/var\"" -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT t-sexputil.o -MD -MP -MF .deps/t-sexputil.Tpo -c -o t-sexputil.o t-sexputil.c > mv -f .deps/t-sexputil.Tpo .deps/t-sexputil.Po > gcc -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -I/Users/ramsey/Developer/MRT/runtime/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/Users/ramsey/Developer/MRT/runtime/lib -lgcrypt -lgpg-error -lassuan -L/Users/ramsey/Developer/MRT/runtime/lib -lgpg-error -L/Users/ramsey/Developer/MRT/runtime/lib -lgpg-error -liconv > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[3]: *** [t-sexputil] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > I'm not sure why this error is occurring, which is why I am reporting it here, per instructions in the README. Am I forgetting to specify an option to configure? Is the configuration subsystem missing something about my system's setup? Please advise. I'm happy to provide any other details if necessary. You'll need to apply the following patch for compiling GnuPG (the patch is made to be applied before ./configure is executed): And most likely, you'll run into another build error in dirmgr. This can be fixed by editing dirmgr/Makefile and deleting "-R/path/to/somewhere" from LDFLAGS -Patrick From sinic at sinic.name Fri Nov 7 22:21:01 2014 From: sinic at sinic.name (Simon Nicolussi) Date: Fri, 7 Nov 2014 22:21:01 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <20141107212101.GA14502@blues.local.sinic.name> The announcement read: > If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.0.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.0.tar.bz2.sig Invoking GnuPG that way is insecure without knowing the contents of the signature file. An attacker could have replaced it by something that's not, in fact, a detached signature. I've attached an exemplary signature file (named gnupg-2.1.0.tar.bz2.sig for your convenience) that demonstrates the problem: > $ echo evil stuff > gnupg-2.1.0.tar.bz2 > $ gpg2 --verify gnupg-2.1.0.tar.bz2.sig > gpg: Signature made Fri Oct 31 07:55:15 2014 CET using RSA key ID 4F25E3B6 > gpg: Good signature from "Werner Koch (dist sig)" [full] Future announcements should call --verify with two files as arguments; the same goes for https://www.gnupg.org/download/integrity_check.html: > gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2.sig -- Simon Nicolussi http{s,}://{www.,}sinic.name/ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.1.0.tar.bz2.sig Type: application/octet-stream Size: 293691 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Sun Nov 9 01:57:58 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 09 Nov 2014 01:57:58 +0100 Subject: some -- are broken in the HTML FAQ Message-ID: <1782372.BjJWreCMQl@inno> Hello, there is a common problem (usually with CMS) in the FAQ: https://www.gnupg.org/faq/gnupg-faq.html There are three ocurrances of "?"; all of them are destroyed "--"s. They are correct in the plain text version. Actually Google pointed me to the outdated version (which has the same problem on a higher level): https://www.gnupg.org/faq/GnuPG-FAQ.html Is there any reason for keeping this document online instead of making a redirection to the new one? And one remark to the content: Using these two principles (the [Landauer bound] and the [Margolus?Levitin limit]), we can determine quite accurately how much heat would be released by a computer that brute-forced a 128-bit cipher. The results are profoundly silly: it?s enough to boil the oceans and leave the planet as a charred, smoking ruin. IIRC this would happen only if this operation was done in a certain, short amount of time so I guess this restriction is missing in the text. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From rjh at sixdemonbag.org Sun Nov 9 02:49:24 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 08 Nov 2014 20:49:24 -0500 Subject: some -- are broken in the HTML FAQ Message-ID: (On from my tablet) What you're looking at is called an em dash (or an en; the FAQ uses both) and is typographically correct. Two hyphens are how people used to simulate an em dash in the ASCII days. Unicode offers proper hyphens, en dashes and em dashes, though, so the FAQ uses them. The remark about imminent heat death is also correct. Hauke Laging wrote: >Hello, > >there is a common problem (usually with CMS) in the FAQ: > >https://www.gnupg.org/faq/gnupg-faq.html > > >There are three ocurrances of "?"; all of them are destroyed "--"s. >They are correct in the plain text version. > > >Actually Google pointed me to the outdated version (which has the same >problem on a higher level): > >https://www.gnupg.org/faq/GnuPG-FAQ.html > >Is there any reason for keeping this document online instead of making a >redirection to the new one? > > >And one remark to the content: > > Using these two principles (the [Landauer bound] and the > [Margolus?Levitin limit]), we can determine quite accurately how much > heat would be released by a computer that brute-forced a 128-bit > cipher. The results are profoundly silly: it?s enough to boil the > oceans and leave the planet as a charred, smoking ruin. > >IIRC this would happen only if this operation was done in a certain, >short amount of time so I guess this restriction is missing in the text. > > >Hauke >-- >Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ >http://userbase.kde.org/Concepts/OpenPGP_Help_Spread >OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 > > >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users From mailinglisten at hauke-laging.de Sun Nov 9 03:03:33 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 09 Nov 2014 03:03:33 +0100 Subject: some -- are broken in the HTML FAQ In-Reply-To: References: Message-ID: <12668903.R64X4Wpe3C@inno> Am Sa 08.11.2014, 20:49:24 schrieb Robert J. Hansen: > What you're looking at is called an em dash (or an en; the FAQ uses > both) and is typographically correct. It is correct if an em dash is meant. It does make absolutely no sense to use a "?" when code is involved where only "--" works. This is about ?? BEGIN instead of -----BEGIN and ?recipient instead of --recipient > Unicode offers proper > hyphens, en dashes and em dashes, though, so the FAQ uses them. No, it doesn't. In 47 of 49 cases it uses "--". I did not want to suggest to replace the dash in "Margolus?Levitin". Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From rjh at sixdemonbag.org Sun Nov 9 04:42:27 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 08 Nov 2014 22:42:27 -0500 Subject: some -- are broken in the HTML FAQ In-Reply-To: <12668903.R64X4Wpe3C@inno> References: <12668903.R64X4Wpe3C@inno> Message-ID: <545EE2A3.6080402@sixdemonbag.org> > and > ?recipient > instead of > --recipient Ah ha. IIRC, those were entered as double hyphens in the source text. I'll double check. From rjh at sixdemonbag.org Sun Nov 9 06:46:31 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 09 Nov 2014 00:46:31 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87h9ybfjjq.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <545BD2F5.4070105@sixdemonbag.org> <87h9ybfjjq.fsf@vigenere.g10code.de> Message-ID: <545EFFB7.1050501@sixdemonbag.org> > Does the method I proposed on wiki.gnupg.org work for you? that is > installing it in the HOME directory with PATH and LD_LIBRARY_PATH > set accordingly? Not really; every time I do some operation requiring a passphrase, GnuPG 2.1 aborts because it can't find a pinentry. From peter at digitalbrains.com Sun Nov 9 11:18:30 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 09 Nov 2014 11:18:30 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <20141107212101.GA14502@blues.local.sinic.name> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> Message-ID: <545F3F76.8050402@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/11/14 22:21, Simon Nicolussi wrote: > Invoking GnuPG that way is insecure without knowing the contents of the > signature file. An attacker could have replaced it by something that's not, > in fact, a detached signature. Oops! Very nice find, kudos! > Future announcements should call --verify with two files as arguments; the > same goes for https://www.gnupg.org/download/integrity_check.html: >> gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2.sig However, here's a small mistake. This should read: gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2 For people not acquainted with this syntax: when --verify has multiple arguments, the first one is the detached signature and the remaining arguments are the signed files. And finally, there is another little thing wrong with the announcement: > GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or direct > from its primary FTP server. The list of mirrors can be found at > https://gnupg.org/mirrors.html . Note that GnuPG is not available at > ftp.gnu.org. That is the list of WWW mirrors. It seems more useful to link to https://gnupg.org/download/mirrors.html . HTH, Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From sinic at sinic.name Sun Nov 9 19:35:06 2014 From: sinic at sinic.name (Simon Nicolussi) Date: Sun, 9 Nov 2014 19:35:06 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <545F3F76.8050402@digitalbrains.com> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <545F3F76.8050402@digitalbrains.com> Message-ID: <20141109183506.GA21982@blues.local.sinic.name> Peter Lebbing wrote: > On 07/11/14 22:21, Simon Nicolussi wrote: > > gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2.sig > > However, here's a small mistake. This should read: > > gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2 Oops, right. I originally used a more concise brace expansion (i.e., gnupg-2.1.0.tar.bz2{.sig,}), but changed my mind the instant before sending. Sorry, I should have proofread my message a second time. -- Simon Nicolussi http{s,}://{www.,}sinic.name/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From patrick at enigmail.net Sun Nov 9 19:39:57 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 09 Nov 2014 19:39:57 +0100 Subject: GnuPG 2.1.0 for Mac OS X Available Message-ID: <545FB4FD.1090504@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm happy to announce the first release of the "GnuPG for OSX" project - - a new distribution of GnuPG 2.1 for Mac OS X ready to download and install. I started "GnuPG for OSX" to provide up to date distributions of GnuPG on Mac. Unlike GPG Tools, this project "only" provides the complete standard gpg tool suite, and no additional software. The distribution requires Mac OS X 10.7 or newer and a 64-bit processor. The software is available from: http://sourceforge.net/projects/gpgosx/files/GnuPG-2.1.0.dmg/download - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUX7T6AAoJEMk25cDiHiw+Kq8IAL2u1dYTniPOpFHvPg5JFM5D EN2ebaLhOfpic6/xZ0BEtaeYWDYa09QaIKsQzRH9q0n03dLEdzrjpLJFSQLuNH4o xjSoJCM3PYtWg7d6ySHPyfePhAKal5u+jQ3z6zsoWccyaNKiHVYvXebU0Nanjr+R RKEi6qdTSD4KcVOVbb0T/wvRjRaJz8lRwFaCXm9nxViaudXko/hQuO3Dl4UY2m/C vGbDMSN4qyICMi7B3uLD/uC1gXnn3zYgXRaZVS3MSkKmAgsHUgsDAEGvzXXhcGmn i7s+JjOrkhStufpahPpDjAsnOXG8Jk12+3GFhRsxTv9RPU5qXdcpfGzv7ZGdt4w= =/cuU -----END PGP SIGNATURE----- From nicholas.cole at gmail.com Sun Nov 9 21:51:43 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 9 Nov 2014 20:51:43 +0000 Subject: GnuPG 2.1.0 for Mac OS X Available In-Reply-To: <545FB4FD.1090504@enigmail.net> References: <545FB4FD.1090504@enigmail.net> Message-ID: Hi Patrick, Thanks for this! It's a really useful resource. Are you able to explain how you managed to get GnuPG-2.1 to compile? N. On Sun, Nov 9, 2014 at 6:39 PM, Patrick Brunschwig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm happy to announce the first release of the "GnuPG for OSX" project > - - a new distribution of GnuPG 2.1 for Mac OS X ready to download and > install. > > I started "GnuPG for OSX" to provide up to date distributions of GnuPG > on Mac. Unlike GPG Tools, this project "only" provides the complete > standard gpg tool suite, and no additional software. > > The distribution requires Mac OS X 10.7 or newer and a 64-bit processor. > > The software is available from: > http://sourceforge.net/projects/gpgosx/files/GnuPG-2.1.0.dmg/download > > - -Patrick > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUX7T6AAoJEMk25cDiHiw+Kq8IAL2u1dYTniPOpFHvPg5JFM5D > EN2ebaLhOfpic6/xZ0BEtaeYWDYa09QaIKsQzRH9q0n03dLEdzrjpLJFSQLuNH4o > xjSoJCM3PYtWg7d6ySHPyfePhAKal5u+jQ3z6zsoWccyaNKiHVYvXebU0Nanjr+R > RKEi6qdTSD4KcVOVbb0T/wvRjRaJz8lRwFaCXm9nxViaudXko/hQuO3Dl4UY2m/C > vGbDMSN4qyICMi7B3uLD/uC1gXnn3zYgXRaZVS3MSkKmAgsHUgsDAEGvzXXhcGmn > i7s+JjOrkhStufpahPpDjAsnOXG8Jk12+3GFhRsxTv9RPU5qXdcpfGzv7ZGdt4w= > =/cuU > -----END PGP SIGNATURE----- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From bighype at gmail.com Sun Nov 9 22:56:33 2014 From: bighype at gmail.com (Mel Brands) Date: Sun, 9 Nov 2014 16:56:33 -0500 Subject: Error building GnuPG modern 2.1.0 on Yosemite In-Reply-To: <87lhnnfr1j.fsf@vigenere.g10code.de> References: <87lhnnfr1j.fsf@vigenere.g10code.de> Message-ID: Werner, Thank you! Patching with -p1 fixed the compilation issue but now I've run into a linking issue (I'm using the latest libgpg-error 1.17). This is the error that occurs near the very end: ------------ gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o libcommon.a ../gl/libgnu.a -L/usr/local/lib -lgcrypt -lgpg-error -lassuan -L/usr/local/lib -lgpg-error -L/usr/local/lib -lgpg-error -liconv Undefined symbols for architecture x86_64: "_default_errsource", referenced from: _parse_ber_header in libcommon.a(libcommon_a-tlv.o) _parse_sexp in libcommon.a(libcommon_a-tlv.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[3]: *** [t-sexputil] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 -------------- According to this post, using a "stable" libgpg-error used to fix this issue back in the May: http://lists.gnupg.org/pipermail/gnupg-users/2014-May/049786.html I've tried Libgpg-error 1.16/1.17 and they have all failed to link properly with Gnupg 2.1.0. Libgpg-error 1.16/1.17 gives identical errors as the one above and 1.15 itself fails to compile with the following: ----------- libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/share/locale\" -g -O2 -Wall -Wpointer-arith -MT libgpg_error_la-estream.lo -MD -MP -MF .deps/libgpg_error_la-estream.Tpo -c estream.c -fno-common -DPIC -o .libs/libgpg_error_la-estream.o estream.c:3502: error: conflicting types for '_gpgrt_fseeko' gpgrt-int.h:108: error: previous declaration of '_gpgrt_fseeko' was here estream.c:3528: error: conflicting types for '_gpgrt_ftello' gpgrt-int.h:110: error: previous declaration of '_gpgrt_ftello' was here make[3]: *** [libgpg_error_la-estream.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ------------- Thanks for any insight! Mel PS: To answer Patrick Brunschwig, I'm using Xcode 6.1 on OS X 10.10 (everything's updated to the latest versions available). On Fri, Nov 7, 2014 at 1:44 AM, Werner Koch wrote: > On Thu, 6 Nov 2014 19:37, bighype at gmail.com said: > > > I tried to compile 2.1.0 today and ran into an issue. I have the > > latest autoconf/m4/gnu toolchain and all of the latest libraries that > > GnuPG needs. > > It is kind of funny that GnuPG as most autoconf enabled programs build > fine on so many Unix platform but not on OS X we should be a modern > Unix. > > One of the reasons might be that GnuPG uses a small part of gnulib (gl/) > but does not follow all the gnulib updates to avoid regressions. > > > ../gl/stdint.h:62:31: error: _types/_intmax_t.h: No such file or > directory > > ../gl/stdint.h:63:32: error: _types/_uintmax_t.h: No such file or > directory > > This problem seems to cause by the hack below. We hoped that this would > fix the problems but obviously it didn't on all machines. You may try > to revert that patch. > > For 2.0.1 I'd really like to get access to a decent OS X box to test the > build before releasing it. > > > Salam-Shalom, > > Werner > > > commit f5592fcff308007322a201c970a6d5e8763c9fe3 > Author: Werner Koch > Date: Wed Oct 29 15:41:28 2014 +0100 > > Fix stdint.h problem for Apple. > > * gl/stdint_.h [__APPLE__]: Include hack. > -- > > Patch suggested by Patrick Brunschwig. > > Modified gl/stdint_.h > diff --git a/gl/stdint_.h b/gl/stdint_.h > index 19577e7..1118e8d 100644 > --- a/gl/stdint_.h > +++ b/gl/stdint_.h > @@ -55,6 +55,13 @@ > # include @ABSOLUTE_STDINT_H@ > #endif > > +#ifdef __APPLE__ > + /* Apple's implementation of is bugy; we therefore use > + the source definitions. */ > +# include <_types/_intmax_t.h> > +# include <_types/_uintmax_t.h> > +#endif > + > /* defines some of the stdint.h types as well, on glibc, > IRIX 6.5, and OpenBSD 3.8 (via ). > MacOS X 10.4.6 includes (which is us), but > > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Mon Nov 10 00:57:16 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 9 Nov 2014 23:57:16 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <1058024917.20141109235716@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 6 November 2014 at 9:01:51 AM, in , Werner Koch wrote: > This is an experimental installer for Windows including > GPA as graphical key manager and GpgEX as an Explorer > extension. Please de-install an already installed > Gpg4win version before trying this installer. This > binary version has not been tested very well, thus it > is likely that you will run into problems. The issue I have encountered (on Windows XP) is not being able to add a Curve 25519 encryption subkey. The option is available, but fails:- Your selection? 12 Please select which elliptic curve you want: (1) Curve 25519 (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 (5) Brainpool P-256 (6) Brainpool P-384 (7) Brainpool P-512 Your selection? 1 gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard. Use this curve anyway? (y/N) y Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: agent_genkey failed: Unknown elliptic curve gpg: Key generation failed: Unknown elliptic curve - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The greater the power, the more dangerous the abuse. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRf/2tXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pmlMD/RNJhby5o/Cv11C0O0R0FLMeNPmXYlslEiE3 sE5qdJ1DZYt/WPrYKVZ3jrSrjFfRWlQ/LlRAsbtu6OhVH4y7Pa0teqNh2xmK1lyH bGeqX0LJtKxf26+wnuwTbP5caj2GB2SgVrSJdmFfUSH91vkLIZebHOhcloZ4kppI r0e/M6fC =C1Vm -----END PGP SIGNATURE----- From mac3iii at gmail.com Mon Nov 10 02:54:47 2014 From: mac3iii at gmail.com (Murphy) Date: Sun, 09 Nov 2014 20:54:47 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <1058024917.20141109235716@my_localhost> References: <1058024917.20141109235716@my_localhost> Message-ID: <54601AE7.8010604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting. That curve doesn't show in the linux build. And neither does option 12 in the 'select what kind of key you want' menu snad at snad:~$ gpg2 --expert --full-gen-key gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) Your selection? 9 Please select which elliptic curve you want: (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 (5) Brainpool P-256 (6) Brainpool P-384 (7) Brainpool P-512 Your selection? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iJwEAQECAAYFAlRgGt8ACgkQUVKxkWZz2Q3a4AP+Ohz0LGNy39O2/nase4NcDPmT k1h+EAYat08S6rV254LUT6qJV0pb4/np59PRa7M6l658YxJeg0cyhOw0IZ+LOjXH noCZAGKPtJEq+ynruybz3K69JR5bDd8YcPBUQaO+RDnQozRd/nvbCdwklfPS/c+l 3wlmNIbCCIWONijgYmw= =tw1d -----END PGP SIGNATURE----- From mac3iii at gmail.com Mon Nov 10 03:09:31 2014 From: mac3iii at gmail.com (Murphy) Date: Sun, 09 Nov 2014 21:09:31 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <54601AE7.8010604@gmail.com> References: <54601AE7.8010604@gmail.com> Message-ID: <54601E5B.4040206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ah, found it under (11) ECC (set your own capabilities) (11) ECC (set your own capabilities) Your selection? 11 Possible actions for a ECDSA key: Sign Certify Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? q Please select which elliptic curve you want: (1) Curve 25519 (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 (5) Brainpool P-256 (6) Brainpool P-384 (7) Brainpool P-512 Your selection? 1 gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard. Use this curve anyway? (y/N) y It generated fine in Linux. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iJwEAQECAAYFAlRgHlsACgkQUVKxkWZz2Q0ftwQAir36kUJq9lF7I0RM+GzyBG6u QIIAVnSivug7PP1Z/TidsFl+ITR4MG5zESud54ZcByqz92k0zzchbShpVDU+39yD Vlxx6jIfKSnQgSNd2ZufLxo6cOmpd3Erex4d8ATrlrCGRHpllHHbFsImNHoxuqyv H/wcIg3pSV3FQLmkuD4= =Rt4/ -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Nov 10 03:36:04 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 10 Nov 2014 02:36:04 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <54601AE7.8010604@gmail.com> References: <1058024917.20141109235716@my_localhost> <54601AE7.8010604@gmail.com> Message-ID: <1569852081.20141110023604@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 10 November 2014 at 1:54:47 AM, in , Murphy wrote: > Interesting. That curve doesn't show in the linux > build. And neither does option 12 in the 'select what > kind of key you want' menu Sorry, I was not clear enough in my description. I created a main key first (tested with RSA main key and also with a couple of the ECC curves). Then I added subkeys via the --edit-key dialogue (addkey). (In that dialogue there is an option 12.) I can ask GnuPG to generate a curve 25519 encryption subkey. But (sub)key generation fails. However, it will generate a curve 25519 signing subkey. > snad at snad:~$ gpg2 --expert --full-gen-key > gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (9) ECC and ECC > (10) ECC (sign only) > (11) ECC (set your own capabilities) > Your selection? 9 I see curve 25519 if I go via option 11 at that point. It can be selected and will create a main key. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net CAUTION! - Beware of Warnings! -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJUYCSfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwrgYH/1shOUrHiunFjBxAMuyLX9qB gW+y9rWmzLhyanHZjn9+TfbNz89Rywg5VitupV8DaY0IUwnx0RnWyqybP7DCci/W NGNbxeL+UXWq1a0E4PWuZb/x8P44HoAEBoQsAAWhR30aZb856m/VjcnqQfoIOF04 KY0VGHwtl+2DU6b90aJ0/BsOrMpOKpdc+nDUGKlji+puYLgfKIfqvy0DZj/EkwiE XspdfKiDsF6TVk17lPDrozkk/lbT7TkNod1P1cxLaXrCwhpUBKOwOpYqI3JIV6Ec 3Mq7zwc+YBaCY9/Esi82QINsWsFMT8rw/2o7pK/ZplppGC51bJbrEWWpugXONBQ= =owMr -----END PGP SIGNATURE----- From mac3iii at gmail.com Mon Nov 10 03:39:01 2014 From: mac3iii at gmail.com (Murphy) Date: Sun, 09 Nov 2014 21:39:01 -0500 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <54601E5B.4040206@gmail.com> References: <54601E5B.4040206@gmail.com> Message-ID: <54602545.6040707@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ok - found the same issue with gpg2 --expert --edit myKey gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 12 Please select which elliptic curve you want: (1) Curve 25519 (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 (5) Brainpool P-256 (6) Brainpool P-384 (7) Brainpool P-512 Your selection? 1 gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard. Use this curve anyway? (y/N) y Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: agent_genkey failed: Unknown elliptic curve gpg: Key generation failed: Unknown elliptic curve So Linux has the same bug. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iJwEAQECAAYFAlRgJUUACgkQUVKxkWZz2Q0/JAP+JoqE96OHIxvjq1bZWAcGn8Ce ZRiw55CzVLHLIg+6XQSujdIdH6onxUhzuP79wcq1ibvfF9GYkfBQgpvDoTj+0T3z n6Yd2Ua0ou1mLSHHNj4my4vJmV1gYD3Ef0ilZ1TJzdNuHG9k7+myI5Q6lfgul2lz ZoTptmcNqjWqoQjT6BM= =ADLB -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Nov 10 03:48:57 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 10 Nov 2014 02:48:57 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <54602209.10209@sumptuouscapital.com> References: <87ioisn1mo.fsf@vigenere.g10code.de> <1058024917.20141109235716@my_localhost> <54602209.10209@sumptuouscapital.com> Message-ID: <915507743.20141110024857@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 10 November 2014 at 2:25:13 AM, in , Kristian Fiskerstrand wrote: > For OpenPGP Curve25519 is only defined[0] for > signatures, certificates, authentication using the > Ed25519 scheme. For encryption the only valid options > are those found in RFC6637[1]. Thanks. That lead me to re-read "What?s new in GnuPG 2.1" [2] and spot, in reference to Curve 25519, the wording "The format for an encryption key has not yet been finalized and will be added to GnuPG in one of the next point releases." [2] - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net You can't build a reputation on what you are going to do -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJUYCesXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwRoYIAI6RIoxX4ih8k9NDCU6aPfbr TqhpE4ec+aNJ1rpaRRm4Oa7AXIovdolrffbG7SJAl03ueryScWUOzj96dm2DKjhK vtM67hZI+KgfMKfl+H2mra9jERJ5vz5KJba0Xsg13NA/0J9rfQdKJIXlTEGDrsbg 4j8fYHFXsmgEzdMNQwB0bOIQcQNAV+zFBdTuGQtwMS7ZfkJbDThP+I3uH2XPFiyb 7iVW3Y3rZYz/vmXaKytSsYmtbaKfp44IcRHKYS0GgC9mF/a1BJbHO2hn/hm17Xf3 lsLv/tAbnX2iH33HZdDOVQavOWC3puUQvT24uh6Om73PcQwXdFlhJh1a5vB7bgo= =Fxxw -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Mon Nov 10 04:02:08 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Mon, 10 Nov 2014 03:02:08 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <54601E5B.4040206@gmail.com> References: <54601AE7.8010604@gmail.com> <54601E5B.4040206@gmail.com> Message-ID: <963618673.20141110030208@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 10 November 2014 at 2:09:31 AM, in , Murphy wrote: > It generated fine in Linux. It did in Windows for a main key, and for a signing subkey. And I now know it can't generate me a Curve 25519 encryption subkey because the format is not yet finalised and will be added in a later GnuPG version. [0] [0] - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Puns are bad but poetry is verse. -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJUYCq6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwcI8IAID0f+DRK6J7BcyDhxxIjKRF q44UEy7xvGI1VoXX2b+gQdSjHR+o6JOL1qN705vpmPzIhHsLQGH0slfo33369PiV i7TXEE+SMc+tM4ayUIqekz79cBKxjMye5TWU6Mr8WL+ByoovorfR2V9MmViQIE23 XiGW+HSEQYL40GwqQknJrrIpzJf2BtwumoGwW7ZvocmDOAcavLIMrLjjxJjpC9+Q 51w9ptDzJpooTBQ3kM6El3saDg32oWhrXJnT7Jvp3+Rn92kbJyNhm+gCkR0FRWd7 5pQPWej19q5PBjUkd4PagqnPZAMh9VHXigT6B/TenM2doJjiVnD2trurFSoJTB4= =RPVm -----END PGP SIGNATURE----- From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 10 03:25:13 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 10 Nov 2014 03:25:13 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <1058024917.20141109235716@my_localhost> References: <87ioisn1mo.fsf@vigenere.g10code.de> <1058024917.20141109235716@my_localhost> Message-ID: <54602209.10209@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/10/2014 12:57 AM, MFPA wrote: > Hi > > > On Thursday 6 November 2014 at 9:01:51 AM, in > , Werner Koch wrote: > > >> This is an experimental installer for Windows including GPA as >> graphical key manager and GpgEX as an Explorer extension. Please >> de-install an already installed Gpg4win version before trying >> this installer. This binary version has not been tested very >> well, thus it is likely that you will run into problems. > > > The issue I have encountered (on Windows XP) is not being able to > add a Curve 25519 encryption subkey. The option is available, but > fails:- > For OpenPGP Curve25519 is only defined[0] for signatures, certificates, authentication using the Ed25519 scheme. For encryption the only valid options are those found in RFC6637[1]. References: [0] http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-01.txt [1] http://tools.ietf.org/rfc/rfc6637.txt - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Ubi mel ibi apes Where there's honey, there are bees -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUYCICAAoJEPw7F94F4Tag0rsP/2I0roSh+4UbtJrTkPW28dA8 F2Nc6qwsXGMI0ZS+8i6uWA3RvaMsTlxaszR7Gi+mko5MGPU3/xFpyj08iT0fb3wp 9K5x2Yzf4x+oAF+cI3XybMaQvteXR0iX7t2ilYPURVoQNJP0R4LfxDvox7VIrJRZ 8YEJRdNmTVDKnFzK+N5xV60cHNgMvhJgF+kgOhMw1dHStps4k3JV/6ETFoRIdmpW e+BqXfrkBl8W7yXubgng5ZubF5belWcPExMLb8qqKNwvHnJwnKfDfvkkqB90uK8h 2VSQweQIf2BqMor0WHxsRfNj7dNNAcRNg36f+t+an0w4v7oA/poYTeT0EAdyJpBZ Q2ldWORP+wdaxJuBdVHlvYKJqSEboDUZcuJLD3MU4YHoL+a8y3Ij14IpMmQ73UoD EpqbN5v5q9zaA8/pQvCdJzkb0OoLSkOZHaWwnDtsrHbR2/BfsJXVMRyU0UhtT6aH pt9ikrQcuxFHNZ0CTPp7XdjSU6KZ67YazN8f1w1jcmffrNdReCX1a2HUkJQ1cAEB pQa7/Yfp4Y3NG5tim4v8OpHX2CHYuzxfRMzyOTTfuj96RB9Lpnzw/9GuiRW/iY3k 6PAiURGw4graoDz9kmamr5BrCt0rkZdInBu08ZconZNqzzh17isAJnGvD3/arQwL gphzOUPSSBZoF4Wu/iXO =65fL -----END PGP SIGNATURE----- From hidekis at gmail.com Mon Nov 10 07:02:17 2014 From: hidekis at gmail.com (Hideki Saito) Date: Sun, 09 Nov 2014 22:02:17 -0800 Subject: Anonymous Receipient is not compatible with ECC? Message-ID: <87d28vlhjq.fsf@mio.hidekisaito.com> Hi I have attempted to use anonymous recipient with ECDH key on 2.1, however, it gives me the following: gpg: encrypted with ECDH key, ID 00000000 gpg: decryption failed: No secret key I can, however, pass --try-secret-key with the appropriate key to force it to decrypt, but it seems like when it tries to decrypt ECC keys that pointing to 0x00000000, it seems to interpret it literally the message intended to that key ID. -- Hideki Saito OpenPGP Key: http://hidekisaito.com/aff2e40b.txt 1066 3928 7B0B E7CD A0CB 3686 1FDF D937 AFF2 E40B http://hidekisaito.com From patrick at enigmail.net Mon Nov 10 08:30:04 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 10 Nov 2014 08:30:04 +0100 Subject: Error building GnuPG modern 2.1.0 on Yosemite In-Reply-To: References: <87lhnnfr1j.fsf@vigenere.g10code.de> Message-ID: <5460697C.7080905@enigmail.net> Apply this patch before doing ./configure and it will build OK: -Patrick On 09.11.14 22:56, Mel Brands wrote: > Werner, > > Thank you! Patching with -p1 fixed the compilation issue but now I've > run into a linking issue (I'm using the latest libgpg-error 1.17). > > This is the error that occurs near the very end: > > ------------ > gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g > -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o > libcommon.a ../gl/libgnu.a -L/usr/local/lib -lgcrypt -lgpg-error > -lassuan -L/usr/local/lib -lgpg-error -L/usr/local/lib -lgpg-error -liconv > Undefined symbols for architecture x86_64: > "_default_errsource", referenced from: > _parse_ber_header in libcommon.a(libcommon_a-tlv.o) > _parse_sexp in libcommon.a(libcommon_a-tlv.o) > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make[3]: *** [t-sexputil] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > -------------- > > According to this post, using a "stable" libgpg-error used to fix this > issue back in the > May: http://lists.gnupg.org/pipermail/gnupg-users/2014-May/049786.html > > I've tried Libgpg-error 1.16/1.17 and they have all failed to link > properly with Gnupg 2.1.0. Libgpg-error 1.16/1.17 gives identical errors > as the one above and 1.15 itself fails to compile with the following: > > ----------- > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. > -DLOCALEDIR=\"/usr/local/share/locale\" -g -O2 -Wall -Wpointer-arith -MT > libgpg_error_la-estream.lo -MD -MP -MF .deps/libgpg_error_la-estream.Tpo > -c estream.c -fno-common -DPIC -o .libs/libgpg_error_la-estream.o > estream.c:3502: error: conflicting types for '_gpgrt_fseeko' > gpgrt-int.h:108: error: previous declaration of '_gpgrt_fseeko' was here > estream.c:3528: error: conflicting types for '_gpgrt_ftello' > gpgrt-int.h:110: error: previous declaration of '_gpgrt_ftello' was here > make[3]: *** [libgpg_error_la-estream.lo] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > ------------- > > Thanks for any insight! > > Mel > > PS: To answer Patrick Brunschwig, I'm using Xcode 6.1 on OS X 10.10 > (everything's updated to the latest versions available). > > On Fri, Nov 7, 2014 at 1:44 AM, Werner Koch > wrote: > > On Thu, 6 Nov 2014 19:37, bighype at gmail.com > said: > > > I tried to compile 2.1.0 today and ran into an issue. I have the > > latest autoconf/m4/gnu toolchain and all of the latest libraries that > > GnuPG needs. > > It is kind of funny that GnuPG as most autoconf enabled programs build > fine on so many Unix platform but not on OS X we should be a modern > Unix. > > One of the reasons might be that GnuPG uses a small part of gnulib (gl/) > but does not follow all the gnulib updates to avoid regressions. > > > ../gl/stdint.h:62:31: error: _types/_intmax_t.h: No such file or directory > > ../gl/stdint.h:63:32: error: _types/_uintmax_t.h: No such file or directory > > This problem seems to cause by the hack below. We hoped that this would > fix the problems but obviously it didn't on all machines. You may try > to revert that patch. > > For 2.0.1 I'd really like to get access to a decent OS X box to test the > build before releasing it. > > > Salam-Shalom, > > Werner > > > commit f5592fcff308007322a201c970a6d5e8763c9fe3 > Author: Werner Koch > > Date: Wed Oct 29 15:41:28 2014 +0100 > > Fix stdint.h problem for Apple. > > * gl/stdint_.h [__APPLE__]: Include hack. > -- > > Patch suggested by Patrick Brunschwig. > > Modified gl/stdint_.h > diff --git a/gl/stdint_.h b/gl/stdint_.h > index 19577e7..1118e8d 100644 > --- a/gl/stdint_.h > +++ b/gl/stdint_.h > @@ -55,6 +55,13 @@ > # include @ABSOLUTE_STDINT_H@ > #endif > > +#ifdef __APPLE__ > + /* Apple's implementation of is bugy; we therefore use > + the source definitions. */ > +# include <_types/_intmax_t.h> > +# include <_types/_uintmax_t.h> > +#endif > + > /* defines some of the stdint.h types as well, on glibc, > IRIX 6.5, and OpenBSD 3.8 (via ). > MacOS X 10.4.6 includes (which is us), but > > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From patrick at enigmail.net Mon Nov 10 08:32:53 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 10 Nov 2014 08:32:53 +0100 Subject: GnuPG 2.1.0 for Mac OS X Available In-Reply-To: References: <545FB4FD.1090504@enigmail.net> Message-ID: <54606A25.5090304@enigmail.net> On 09.11.14 21:51, Nicholas Cole wrote: > Hi Patrick, > > Thanks for this! It's a really useful resource. > > Are you able to explain how you managed to get GnuPG-2.1 to compile? See the scripts in the git source tree: https://sourceforge.net/p/gpgosx/source/ci/master/tree/create_gpg I have XCode 6.1 plus a very small set of tools from MacPorts (wget, pkg-config). -Patrick From wk at gnupg.org Mon Nov 10 09:49:30 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Nov 2014 09:49:30 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <545EFFB7.1050501@sixdemonbag.org> (Robert J. Hansen's message of "Sun, 09 Nov 2014 00:46:31 -0500") References: <87ioisn1mo.fsf@vigenere.g10code.de> <545BD2F5.4070105@sixdemonbag.org> <87h9ybfjjq.fsf@vigenere.g10code.de> <545EFFB7.1050501@sixdemonbag.org> Message-ID: <87bnofbftx.fsf@vigenere.g10code.de> On Sun, 9 Nov 2014 06:46, rjh at sixdemonbag.org said: > Not really; every time I do some operation requiring a passphrase, GnuPG > 2.1 aborts because it can't find a pinentry. Hey, it is a wiki - feel free to put in your solution - in case it is different than mine. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 10 09:48:28 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Nov 2014 09:48:28 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <20141107212101.GA14502@blues.local.sinic.name> (Simon Nicolussi's message of "Fri, 7 Nov 2014 22:21:01 +0100") References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> Message-ID: <87fvdrbfvn.fsf@vigenere.g10code.de> On Fri, 7 Nov 2014 22:21, sinic at sinic.name said: > Invoking GnuPG that way is insecure without knowing the contents of the > signature file. An attacker could have replaced it by something that's > not, in fact, a detached signature. I guess that this bug exists at least since 1.0.4 and I consider this a serious flaw. I am thinking about a proper solution which limts breakage. As a quick minimal fix I changed the instructions on the website. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Mon Nov 10 12:02:06 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 10 Nov 2014 11:02:06 +0000 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <20141107212101.GA14502@blues.local.sinic.name> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> Message-ID: On Fri, Nov 7, 2014 at 9:21 PM, Simon Nicolussi wrote: > The announcement read: >> If you already have a version of GnuPG installed, you can simply >> verify the supplied signature. For example to verify the signature >> of the file gnupg-2.1.0.tar.bz2 you would use this command: >> >> gpg --verify gnupg-2.1.0.tar.bz2.sig > > Invoking GnuPG that way is insecure without knowing the contents of the > signature file. An attacker could have replaced it by something that's > not, in fact, a detached signature. > > I've attached an exemplary signature file (named gnupg-2.1.0.tar.bz2.sig > for your convenience) that demonstrates the problem: >> $ echo evil stuff > gnupg-2.1.0.tar.bz2 >> $ gpg2 --verify gnupg-2.1.0.tar.bz2.sig >> gpg: Signature made Fri Oct 31 07:55:15 2014 CET using RSA key ID 4F25E3B6 >> gpg: Good signature from "Werner Koch (dist sig)" [full] > > Future announcements should call --verify with two files as arguments; > the same goes for https://www.gnupg.org/download/integrity_check.html: >> gpg --verify gnupg-2.1.0.tar.bz2.sig gnupg-2.1.0.tar.bz2.sig Is the point that you can have a signed file that makes you THINK you have verified a file when in fact you haven't? So the confusion is that you have one single command that deals with verifying both a detached signature and with a file that contains a signature? Is the best fix for this to introduce two new commands --verify-detached (requires two arguments) and --verify-file and then to make everything that simply calls the old command --verify break? Or is that too radical? N. From nicholas.cole at gmail.com Mon Nov 10 12:52:44 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 10 Nov 2014 11:52:44 +0000 Subject: GnuPG 2.1 Unattended EC Generation Message-ID: Dear List, How does unattended generation of elliptic curve keys work? As far as I can see, that section of the manual has not been updated for the new EC options, but I presume that it has to work slightly differently. Am I right that key-length is now a no-op? And how do you specify the curve? Best wishes, N. From nicholas.cole at gmail.com Mon Nov 10 12:53:58 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 10 Nov 2014 11:53:58 +0000 Subject: ECDSA vs EDDSA Message-ID: In the new gpg2 --version lists both ECDSA and EDDSA as supported algorithms, but that doesn't seem to correspond to options in the --expert --full-gen-key command. I presume that --full-gen-key creates an ECDSA by default. Is that right? Perhaps someone who knows about EC could write an FAQ on the wiki for those of us who are confused by all the new options? Yes, I know that for ordinary use we should all just use the defaults, but I'd still like to know what is going on, for interest's sake. N. From peter at digitalbrains.com Mon Nov 10 12:59:15 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 10 Nov 2014 12:59:15 +0100 Subject: Detached signature ambiguity (was: [Announce] GnuPG 2.1.0 "modern" released) In-Reply-To: References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> Message-ID: <5460A893.6090904@digitalbrains.com> On 10/11/14 12:02, Nicholas Cole wrote: > So the confusion is > that you have one single command that deals with verifying both a > detached signature and with a file that contains a signature? Yes. > Is the best fix for this to introduce two new commands That seems extreme. Although you could add commands that make it explicit what you want, removing the existing, ambiguous one would cause massive breakage of deployed scripts. Werner is always very cautious about doing that. Maybe this avenue of thought can help come up with a good solution. When people verify a detached signature, they usually have two files named: file.ext file.ext.sig If GnuPG encounters this situation, but file.ext.sig is not a detached signature, it could display a big fat warning: WARNING: file.ext.sig is NOT a detached signature; the file file.ext is NOT VERIFIED! This does create some related issues: gnupg_2.1.0.tar.bz2 gnupg-2.1.0.tar.bz2.sig or gnupg_2,1.0.tar.bz2.sig These files can trick people into thinking they have the same filename. This suggests this is either not foolproof or you need normalisation. The extent of normalisation seems to make this unattainable. And combining Unicode characters make matters even worse. So it definitely has problems. But it might help think of the most proper solution. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From nicholas.cole at gmail.com Mon Nov 10 13:00:11 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 10 Nov 2014 12:00:11 +0000 Subject: DSA key sizes Message-ID: Just out of curiosity: DSA key sizes are now rounded to one of 3 values, whereas RSA keys are available in a range of sizes between two limits. Why the difference? Nicholas From nicholas.cole at gmail.com Mon Nov 10 13:03:41 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 10 Nov 2014 12:03:41 +0000 Subject: Detached signature ambiguity (was: [Announce] GnuPG 2.1.0 "modern" released) In-Reply-To: <5460A893.6090904@digitalbrains.com> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <5460A893.6090904@digitalbrains.com> Message-ID: On Mon, Nov 10, 2014 at 11:59 AM, Peter Lebbing wrote: > On 10/11/14 12:02, Nicholas Cole wrote: >> So the confusion is >> that you have one single command that deals with verifying both a >> detached signature and with a file that contains a signature? > > Yes. > >> Is the best fix for this to introduce two new commands > > That seems extreme. Although you could add commands that make it > explicit what you want, removing the existing, ambiguous one would cause > massive breakage of deployed scripts. Werner is always very cautious > about doing that. > > Maybe this avenue of thought can help come up with a good solution. When > people verify a detached signature, they usually have two files named: > > file.ext > file.ext.sig > > If GnuPG encounters this situation, but file.ext.sig is not a detached > signature, it could display a big fat warning: > > WARNING: file.ext.sig is NOT a detached signature; the file file.ext is > NOT VERIFIED! Yes, Werner is very good at not breaking things that don't need to be broken. But in fact, it is the fact that scripts depend on this that made me think that this might be a case where things *should* get broken, because this is actually a serious security flaw, and the scripts in question need fixing. In many cases, no one is going to be around to read the warning you suggest. Just a thought. N. From peter at digitalbrains.com Mon Nov 10 13:16:06 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 10 Nov 2014 13:16:06 +0100 Subject: ECDSA vs EDDSA In-Reply-To: References: Message-ID: <5460AC86.2000500@digitalbrains.com> I can give two significant differences between ECDSA and EdDSA: 1) Signature creation is deterministic in EdDSA; ECDSA requires high quality randomness for each and every signature to be safe (just as regular ol' DSA). If low-quality randomness is used an attacker can compute the private key. Using XKCD's get_random()[1] function as in the Playstation 3 (as exposed by Fail0verflow) makes it trivial to compute the private key. More specifically, using the same random number for two different signatures is enough to trivially compute it. Werner has mentioned that deterministic operation is a prerequisite for him to consider an OpenPGP Card smartcard implementation due to lack of trust in on-card generated entropy. 2) The process by which the actual parameters of Ed25519 have been chosen is completely open. It is possible to create a backdoor by very careful choice of the parameters; this means that there exists a chance that the NIST and (I believe also) the Brainpool curves have been chosen in a way that there is a secret backdoor only known to the organisation that selected the parameters. The parameters I'm talking about are the ones shared by all keys on a specific curve; the actual private key is still chosen by the creator of the key and is not what I mean. Point 1) turns my thoughts to a related issue. Is there still any reason to include deterministic classic DSA in OpenPGP or is that a bit late to the party? HTH, Peter. [1] int get_random() { return 4; // Chosen by fair dice roll; guaranteed to be random } That's from memory, it might not be fully literal. Also, that XKCD comic was actually one of the presentation slides of Fail0verflow; I was there at the 27C3 when they revealed their hack, so cool! -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Mon Nov 10 13:25:53 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 10 Nov 2014 13:25:53 +0100 Subject: Detached signature ambiguity In-Reply-To: References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <5460A893.6090904@digitalbrains.com> Message-ID: <5460AED1.1020509@digitalbrains.com> On 10/11/14 13:03, Nicholas Cole wrote: > But in fact, it is the fact that scripts depend on this that made me > think that this might be a case where things *should* get broken, > because this is actually a serious security flaw, and the scripts in > question need fixing. In many cases, no one is going to be around to > read the warning you suggest. Hmmm, very solid point... unfortunately :(. Not a pretty situation to be in at all... It still suggests to me it should only break when normally there would be a detached signature verified (i.e., without the .sig extension) but it is not because it is not a detached signature. I suppose these scripts wouldn't work anyway when files are named as in my problematic example: gnupg_2.1.0.tar.bz2 gnupg-2.1.0.tar.bz2.sig So simply returning error in the case where there /is/ a full match seems to fix the scripting case. It still leaves the user-driven case, because the user can still be foiled by a single-character change. It might be possible for an attacker to force a signature verification failure of a script if he can name files in the same directory. Suppose a script is supposed to verify ledger.csv.asc, which is /not/ a detached signature, but simply has the data embedded. An attacker could create a file in the same dir with the name ledger.csv and cause the ambiguity detecting mechanism to trigger falsely, leading to signature verification failure. Whether this is a real issue, I don't know. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dshaw at jabberwocky.com Mon Nov 10 14:32:52 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 10 Nov 2014 08:32:52 -0500 Subject: DSA key sizes In-Reply-To: References: Message-ID: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> On Nov 10, 2014, at 7:00 AM, Nicholas Cole wrote: > Just out of curiosity: DSA key sizes are now rounded to one of 3 > values, whereas RSA keys are available in a range of sizes between two > limits. Why the difference? FIPS-186-3, the document that specifies DSS (aka DSA with some additional restrictions as to algorithm, key length, etc) specifies 4 key sizes: 1024 bit key, 160 bit hash 2048-bit key, 224 bit hash 2048-bit key, 256 bit hash 3072-bit key, 256 bit hash. To be closer to FIPS, GnuPG rounds up to the next 1024-bit boundary when making DSA keys. The hash rules are keys 2048 bits and over use a 256-bit hash, keys over 1024 bits use a 224 bit hash, and 1024 and under use a 160 bit hash (classic DSA). GnuPG skips the 2048/224 option in favor of 2048/256. In --expert mode you can select whatever key size you like without rounding, but the same hash size rules still apply. David From rjh at sixdemonbag.org Mon Nov 10 14:52:08 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 08:52:08 -0500 Subject: DSA key sizes In-Reply-To: References: Message-ID: <5460C308.6010009@sixdemonbag.org> > Just out of curiosity: DSA key sizes are now rounded to one of 3 > values, whereas RSA keys are available in a range of sizes between two > limits. Why the difference? >From the FAQ: "11.10 Why is my DSA key limited to 3072 bits? The United States? National Institute of Standards and Technology (NIST) is responsible for the DSA specification. NIST has not published a 4096-bit DSA variant, and thus GnuPG doesn?t offer it." From rjh at sixdemonbag.org Mon Nov 10 14:56:36 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 08:56:36 -0500 Subject: DSA key sizes In-Reply-To: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> References: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> Message-ID: <5460C414.8050401@sixdemonbag.org> > FIPS-186-3, the document that specifies DSS (aka DSA with some > additional restrictions as to algorithm, key length, etc) specifies 4 > key sizes: Five, but nobody uses DSA-512 and I think it's been formally obsoleted. But yes, DSA-512 is a real thing, although GnuPG never supported it (for good reasons -- it was seen as marginal even when it first came out!). From bernhard at intevation.de Mon Nov 10 15:00:09 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Nov 2014 15:00:09 +0100 Subject: GnuPG 2.1.0 for Mac OS X Available In-Reply-To: <545FB4FD.1090504@enigmail.net> References: <545FB4FD.1090504@enigmail.net> Message-ID: <201411101500.15898.bernhard@intevation.de> Patrick, On Sunday 09 November 2014 at 19:39:57, Patrick Brunschwig wrote: > http://sourceforge.net/projects/gpgosx/files/GnuPG-2.1.0.dmg/download thanks for letting us know and for publishing Free Software! I've added a link to the wiki.gnupg.org. One suggestion: I probably wouldn't hurt if you'd explained how to use the sf way of receiving a checksum of the files to be downloaded. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Nov 10 15:20:11 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 10 Nov 2014 15:20:11 +0100 Subject: GPG API: Open Crypto Engine In-Reply-To: <20141107113836hzRDhd8N8b@goodcrypto.com> References: <20141107113836hzRDhd8N8b@goodcrypto.com> Message-ID: <201411101520.22028.bernhard@intevation.de> Nan, On Friday 07 November 2014 at 12:38:36, Nan wrote: > The Open Crypto Engine is one API for multiple crypto plugins. Open source. > We've released a Python version with a gpg plugin at > https://gibhub.com/goodcrypto/. There's also a java version with more > plugins. thanks for the hint, I've added a first link to the wiki.gnupg.org in applications that use GnuPG. It gave me two questions right away: * Is there a documentation for the API? * Do you use gpgme? Best, Bernhard # At least the "elliptic curves" are bad notion is not understandable to me from the FAQ. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 10 15:32:54 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 10 Nov 2014 15:32:54 +0100 Subject: ECDSA vs EDDSA In-Reply-To: <5460AC86.2000500@digitalbrains.com> References: <5460AC86.2000500@digitalbrains.com> Message-ID: <5460CC96.1060001@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/10/2014 01:16 PM, Peter Lebbing wrote: > I can give two significant differences between ECDSA and EdDSA: > > 1) Signature creation is deterministic in EdDSA; ECDSA requires > high quality randomness for each and every signature to be safe > (just as regular ol' DSA). If low-quality randomness is used an > attacker can This is not necessarily true if [RFC6979]: "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)" is used. References: [RFC6979] http://tools.ietf.org/rfc/rfc6979.txt - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "If the facts don't fit the theory, change the facts" (Albert Einstein) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUYMyUAAoJEPw7F94F4TagYjwP/33PRICPNQj2KoI381bnV/cG 0I1AXjSrYMIsq4C+BAyA3gR78YJLnbJ6Y/p8DMg+tTX/sHiSlpxHZvFTVRZzuzYT EOlssOpEFLIu8zGUXbkkLIlB8KDHL9L+XWDnU+VUC28TRj/6+QDAIQnz+JoOpQ4m IT2BwDaQkqkyHzialzB9bER6wjC5BdN83x5Qgjoyt+0I6yrtWrqItVjQspXp5gQC jaoBQKM5fV87xZu02qXLmzy9/ZnNA13JP8+tagwzVbiS+1dvCDhKG1NxVvtz9blB UXpb2Y3GwmfSIRop064JyMFkV5CqPCcDmrwu5IryPpp98N2DeMlDsd0UCL/eKykZ 1XTCKmypM4NOAybdMDA0q2GLI/Ab9UK/iA1QdU9Do8+3hC6nqS73yf0DSjWQoKzz wwjyYGx/NJM5NfDrnNNjiMQmqnONSCy9eB/V92Azqed7M8YS1oY0X9vDfUK4rJ9L rl/0W2pHHRkprwJRHoyAmQClXUABnALT9vptJtxqCqbdbNysYxbWpUUQnQzuM8Ft 63b0Ov3eaAgqSDEFiLVqtAD6Wa/d+EWm7LxgPn03d0gENq5yCx4yhflkxYuexKpk /JveJr6/oFTD7M05jQrSvnwVGtiyZV6DpyWdGuMbNmVPPOuHH772yevnR2xJ3AMP f8KJbOm+IRliVU7aWunp =RNmo -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Mon Nov 10 15:48:16 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 09:48:16 -0500 Subject: DSA key sizes In-Reply-To: <5460C414.8050401@sixdemonbag.org> References: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> <5460C414.8050401@sixdemonbag.org> Message-ID: <5460D030.3060804@sixdemonbag.org> > Five, but nobody uses DSA-512 and I think it's been formally obsoleted. Whoops! After going back to my sources to double-check this, it turns out to be a lot more than 5. DSA was defined in DSA-512 to DSA-1024 at 64-bit steps -- so weird ones like DSA-576 exist, too. From dshaw at jabberwocky.com Mon Nov 10 16:04:50 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 10 Nov 2014 10:04:50 -0500 Subject: DSA key sizes In-Reply-To: <5460C414.8050401@sixdemonbag.org> References: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> <5460C414.8050401@sixdemonbag.org> Message-ID: On Nov 10, 2014, at 8:56 AM, Robert J. Hansen wrote: >> FIPS-186-3, the document that specifies DSS (aka DSA with some >> additional restrictions as to algorithm, key length, etc) specifies 4 >> key sizes: > > Five, but nobody uses DSA-512 and I think it's been formally obsoleted. > But yes, DSA-512 is a real thing, although GnuPG never supported it > (for good reasons -- it was seen as marginal even when it first came out!). No, four. Section 4.2 of FIPS-186-3: This Standard specifies the following choices for the pair L and N (the bit lengths of p and q, respectively): L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf Remember that the FIPS-186 documents cover DSS, not DSA. There was a < 1024-bit DSS, but it didn't make it into FIPS-186-3. It's also not the case the GnuPG never supported 512-bit DSA. You could generate a 512-bit DSA until 1024 was made the minimum in late 2004. Even today, it's possible to generate a 512 bit DSA key in 1.4.x if you use --expert. (Not that you should). David From rjh at sixdemonbag.org Mon Nov 10 17:01:12 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 11:01:12 -0500 Subject: DSA key sizes In-Reply-To: References: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> <5460C414.8050401@sixdemonbag.org> Message-ID: <5460E148.7030803@sixdemonbag.org> > No, four. Section 4.2 of FIPS-186-3: Yeah, I was misled by the reference to 186-3 and misread it as "the family of 186 documents." (For those of you who don't follow government specs as a hobby: FIPS 186, first released in 1994, has been revised several times over the years. We're now up to the fifth revision, FIPS 186-4, which was published in July of 2013.) > Remember that the FIPS-186 documents cover DSS, not DSA. There was a > < 1024-bit DSS, but it didn't make it into FIPS-186-3. I don't have a copy of FIPS 186-3, but my copy of 186-4 has a chapter 4 titled "The Digital Signature Algorithm." The document *itself* is called the Digital Signature Standard, but there's nothing in the text that says "this particular algorithm with these particular parameters represents DSS". (This is a break of sorts from FIPS 186, where "DSS" was used in the text a couple of times in an algorithmic context. I don't know when the language shift happened, but clearly somewhere between 186 and 186-4.) > It's also not the case the GnuPG never supported 512-bit DSA. Huh: interesting. From wk at gnupg.org Mon Nov 10 17:31:47 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Nov 2014 17:31:47 +0100 Subject: ECDSA vs EDDSA In-Reply-To: <5460CC96.1060001@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 10 Nov 2014 15:32:54 +0100") References: <5460AC86.2000500@digitalbrains.com> <5460CC96.1060001@sumptuouscapital.com> Message-ID: <87tx279fv0.fsf@vigenere.g10code.de> On Mon, 10 Nov 2014 15:32, kristian.fiskerstrand at sumptuouscapital.com said: > This is not necessarily true if [RFC6979]: "Deterministic Usage of the > Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature > Algorithm (ECDSA)" is used. Which is used in 2.1: commit 6466db10fb22a4f24df4edad9c5cb33ec67321bd Author: Werner Koch Date: Sat Sep 7 10:06:46 2013 +0200 Switch to deterministic DSA. * agent/pksign.c (rfc6979_hash_algo_string): New. (do_encode_dsa) [Libgcrypt >= 1.6]: Make use of RFC-6979. -- Now that we have a good (and not NSA/NIST demanded ;-) specification on how to use DSA without a random nonce, we take advantage of it and thus avoid pitfalls related to a misbehaving RNG during signature creation. Note that OpenPGP has the option of using a longer hash algorithm but truncated to what is suitable for the used DSA key size. The hash used as input to RFC-6979 will also be one with an appropriate digest length but not a truncated one. This is allowed by RFC-6979. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 10 17:41:11 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Nov 2014 17:41:11 +0100 Subject: GnuPG 2.1 Unattended EC Generation In-Reply-To: (Nicholas Cole's message of "Mon, 10 Nov 2014 11:52:44 +0000") References: Message-ID: <87ppcv9ffc.fsf@vigenere.g10code.de> On Mon, 10 Nov 2014 12:52, nicholas.cole at gmail.com said: > How does unattended generation of elliptic curve keys work? As far as > I can see, that section of the manual has not been updated for the new > EC options, but I presume that it has to work slightly differently. > Am I right that key-length is now a no-op? And how do you specify the Right, you need to use "Key-Curve" or "Subkey-Curve". Curve names are as supported by Libgcrypt, for example: "nistp256" or "ed25519". Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pete at heypete.com Mon Nov 10 18:01:00 2014 From: pete at heypete.com (Pete Stephenson) Date: Mon, 10 Nov 2014 18:01:00 +0100 Subject: ECDSA vs EDDSA In-Reply-To: <5460AC86.2000500@digitalbrains.com> References: <5460AC86.2000500@digitalbrains.com> Message-ID: On Mon, Nov 10, 2014 at 1:16 PM, Peter Lebbing wrote: > I can give two significant differences between ECDSA and EdDSA: > > 1) Signature creation is deterministic in EdDSA; ECDSA requires high > quality randomness for each and every signature to be safe (just as > regular ol' DSA). If low-quality randomness is used an attacker can > compute the private key. Using XKCD's get_random()[1] function as in the > Playstation 3 (as exposed by Fail0verflow) makes it trivial to compute > the private key. More specifically, using the same random number for two > different signatures is enough to trivially compute it. > > Werner has mentioned that deterministic operation is a prerequisite for > him to consider an OpenPGP Card smartcard implementation due to lack of > trust in on-card generated entropy. As Kristian mentioned, deterministic DSA [RFC 6979] solves this problem for both regular DSA and ECDSA. I've been under the (possibly erroneous) impression that GnuPG has used deterministic DSA for some time now. I'd hope that it does the same for ECDSA. If so, a quality source of randomness is needed only for key generation, not for each signature. > 2) The process by which the actual parameters of Ed25519 have been > chosen is completely open. It is possible to create a backdoor by very > careful choice of the parameters; this means that there exists a chance > that the NIST and (I believe also) the Brainpool curves have been chosen > in a way that there is a secret backdoor only known to the organisation > that selected the parameters. While the NIST curves are suspicious in that they utilize an unexplained "random" seed[1], I don't see how the Brainpool curves were chosen for nefarious purposes. Indeed, pages 6 and 7 of http://www.ecc-brainpool.org/download/Domain-parameters.pdf shows the exact process to derive both the seed and the pseudo-random primes used in those curves. At http://safecurves.cr.yp.to/rigid.html, djb says the Brainpool curves are "mostly rigid" and has only a limited number of criticisms: "Why SHA-1 instead of, e.g., RIPEMD-160 or SHA-256? Why use 160 bits of hash input independently of the curve size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle separate key sizes by more digits of pi and e instead of hash derivation? Why counter mode instead of, e.g., OFB? Why use overlapping counters for A and B (producing the repeated 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B?" There's several other standards (such as RCF 3526) that generate primes, in part, using large powers of pi. It seems to me to be a reasonable "nothing up my sleeve" number. As for the other concerns, would the use of (for example) SHA1 vs. SHA256 or the use of counter mode as part of the generation algorithm give the malicious standards-writer some advantage? Maybe, but it seems much less likely to be manipulated than, say, the NIST curves or ANSSI FRP256v1, and more likely to be the result of some ordinary technical decision-making. [1] It's certainly possible that NIST/NSA just used /dev/random or some other quality source of randomness for the seed, but there's no way to *prove* that, so the seeds for the NIST curves are not above suspicion. Still, it would require a *lot* of effort to get a particular output of SHA1 that had certain useful properties. Would the NSA expend that effort? Who knows? Cheers! -Pete -- Pete Stephenson From nan at goodcrypto.com Mon Nov 10 18:14:10 2014 From: nan at goodcrypto.com (Nan) Date: Mon, 10 Nov 2014 17:14:10 GMT Subject: GPG API: Open Crypto Engine Message-ID: <20141110171410cQwKOe9HNd@goodcrypto.com> >I've added a first link to the wiki.gnupg.org in applications that use GnuPG. Thank you, Bernhard. I noticed you had a few "TODOs" in the wiki. Would you like me to modify the entry? >Is there a documentation for the API? Yes. Standard "pydoc MODULE". For example, to see the docs for gpg_plugin.py, you'd type: pydoc goodcrypto.oce.gpg_plugin If you prefer docs in HTML, then add -w before the module name. If anyone needs help, then they can ask on this mailing list or via support at g[you know] >Do you use gpgme? No. OCE predates GPGME. Thanks again, Bernard. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From nan at goodcrypto.com Mon Nov 10 18:34:34 2014 From: nan at goodcrypto.com (Nan) Date: Mon, 10 Nov 2014 17:34:34 GMT Subject: DSA key sizes Message-ID: <20141110173434qpTxUGZCgP@goodcrypto.com> Nicholas, DSA was certainly compromised in the past. Some people think it isn't anymore. It doesn't matter much whether NIST knew or was conned. NIST didn't change their Elliptic Curve spec until Snowden published proof of a backdoor. Then they adjusted the spec as little as possible. NIST's DSA standard has shifted similarly. In our view it's generally better to avoid state sponsored standards. >From https://goodcrypto.com/qna/technical/dsa-flaws/: DSA (U.S. Digital Signature Algorithm) keys haven't made the news, but they should. Here's a sentence from the ssh-keygen man page: DSA keys must be exactly 1024 bits as specified by FIPS 186-2. First, why should the whole world be restricted by a U.S. FIPS (Federal Information Processing Standard)? In this case it's obvious. NSA very likely has rainbow tables for DSA 1024 bit keys. The standard was compromised right in the open by not allowing longer keys. But it's worse than it appears. The SSH spec says "exactly 1024 bits", not "1024 bits or less". Why? Because NSA wanted the key length to sound as safe as possible, but still make everyone vulnerable to their attacks. Rainbow tables take a lot of resources to generate. The spec says "exactly" because that rainbow table is half of the size of a rainbow table for "1024 bits or less". NSA specified "exactly" 1024 bits to cut their work in half. The standard has been updated, but ssh-keygen shows their past behavior. We see no reason to believe it has changed. More detail: X is the size of the table at exactly 1024 bits. The table size for 1023 is 1/2 X, for 1022 it's 1/4 X, etc. Then (X + 1/2 X + 1/4 X + ...) is 2X. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From rjh at sixdemonbag.org Mon Nov 10 18:36:01 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 12:36:01 -0500 Subject: DSA key sizes In-Reply-To: <5460E148.7030803@sixdemonbag.org> References: <01E114FD-5D53-4F9B-AA96-3AFF29C8052A@jabberwocky.com> <5460C414.8050401@sixdemonbag.org> <5460E148.7030803@sixdemonbag.org> Message-ID: <5460F781.5000400@sixdemonbag.org> > We're now up to the fifth revision, FIPS 186-4 Fifth *release*. Fourth revision. Sorry. From aarcane at aarcane.org Mon Nov 10 18:58:04 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Mon, 10 Nov 2014 09:58:04 -0800 Subject: DSA key sizes In-Reply-To: <20141110173434qpTxUGZCgP@goodcrypto.com> References: <20141110173434qpTxUGZCgP@goodcrypto.com> Message-ID: I'm going to go out on a limb and suggest that gpg should support government sponsored cryptographic standards whenever possible, but should consider the highest government sponsored requirement as a minimum requirement to actually implement. DSA 4096, 5120, and 8192 should be available when governments advocate 3072. Governments are notorious for understating cryptography requirements. I also find the rainbow table fairly probable. Someone on this list should start a project to compute one on Amazon s3 and see how long it would take and how much it would cost. Given the recent demonstration of an md5 break for less than a dollar on s3 gpu nodes, I'd not be surprised to see it in under a year. On Nov 10, 2014 9:39 AM, "Nan" wrote: > Nicholas, > > DSA was certainly compromised in the past. Some people think it isn't > anymore. > > It doesn't matter much whether NIST knew or was conned. NIST didn't change > their Elliptic Curve spec until Snowden published proof of a backdoor. Then > they adjusted the spec as little as possible. NIST's DSA standard has > shifted similarly. > > In our view it's generally better to avoid state sponsored standards. > > >From https://goodcrypto.com/qna/technical/dsa-flaws/: > > DSA (U.S. Digital Signature Algorithm) keys haven't made the news, but > they should. Here's a sentence from the ssh-keygen man page: > > DSA keys must be exactly 1024 bits as specified by FIPS 186-2. > > First, why should the whole world be restricted by a U.S. FIPS (Federal > Information Processing Standard)? In this case it's obvious. NSA very > likely has rainbow tables for DSA 1024 bit keys. The standard was > compromised right in the open by not allowing longer keys. > > But it's worse than it appears. The SSH spec says "exactly 1024 bits", not > "1024 bits or less". Why? Because NSA wanted the key length to sound as > safe as possible, but still make everyone vulnerable to their attacks. > > Rainbow tables take a lot of resources to generate. The spec says > "exactly" because that rainbow table is half of the size of a rainbow table > for "1024 bits or less". NSA specified "exactly" 1024 bits to cut their > work in half. > > The standard has been updated, but ssh-keygen shows their past behavior. > We see no reason to believe it has changed. > > More detail: X is the size of the table at exactly 1024 bits. The table > size for 1023 is 1/2 X, for 1022 it's 1/4 X, etc. Then (X + 1/2 X + 1/4 X + > ...) is 2X. > > Nan > > GoodCrypto warning: Anyone could have read this message. Use encryption, > it works. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonneau at sanboa.info Mon Nov 10 15:40:34 2014 From: bonneau at sanboa.info (bonneau at sanboa.info) Date: Mon, 10 Nov 2014 15:40:34 +0100 Subject: GnuPG 2.1.0 for Mac OS X Available In-Reply-To: <54606A25.5090304@enigmail.net> References: <545FB4FD.1090504@enigmail.net> <54606A25.5090304@enigmail.net> Message-ID: <71E251DE-8946-442B-B56E-184CA5C1A54F@sanboa.info> I thank you also, Patrick, for these informations and especially for your work in everyone's interest. In French, we say : "chapeau bas" (hat down, sir) for your "share motion" if my english is correct. I'll take time for installing this software in the coming days on my Mac Book Air (10.9), reading the managing way you provide. I will probably tell you a few naive questions : I ask your indulgence in advance. To-day, as you will see, this older computer is on Mac OS X 10.6.8. Perhaps (or not ?), will it be also possible installing GnuPG on it, in a few months. Kind regards Alain Le 10 nov. 2014 ? 08:32, Patrick Brunschwig a ?crit : > On 09.11.14 21:51, Nicholas Cole wrote: >> Hi Patrick, >> >> Thanks for this! It's a really useful resource. >> >> Are you able to explain how you managed to get GnuPG-2.1 to compile? > > See the scripts in the git source tree: > https://sourceforge.net/p/gpgosx/source/ci/master/tree/create_gpg > > I have XCode 6.1 plus a very small set of tools from MacPorts (wget, > pkg-config). > > -Patrick > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Mon Nov 10 19:31:04 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 13:31:04 -0500 Subject: DSA key sizes In-Reply-To: <20141110173434qpTxUGZCgP@goodcrypto.com> References: <20141110173434qpTxUGZCgP@goodcrypto.com> Message-ID: <54610468.3060005@sixdemonbag.org> > DSA was certainly compromised in the past. Some people think it isn't > anymore. This is news to the cryptographic community. Cite, please? I want to know who these "some people" are, and a list of their major academic publications. If Dan Boneh says DSA is compromised, I'll have a coronary and I'll rush to read the paper proving it. If Joe Bob's Web Page Of Crypto says DSA is compromised, I'm going to yawn and click "Back". > It doesn't matter much whether NIST knew or was conned. NIST didn't > change their Elliptic Curve spec until Snowden published proof of a > backdoor. NIST's DSA standard has never been compromised, nor did Snowden release any proof of a backdoor in a NIST DSA standard. (I know, I know, Nan is just saying "elliptic curve spec". Given the sentence is embedded in some talk about DSA, I think it's reasonable to think Nan's talking about ECDSA.) What Nan means to be talking about is the Dual Elliptical Curve Deterministic Random Bit Generator (Dual_EC_DRBG) specification -- a way of generating random numbers, but *not* a signature algorithm. It was released in 2004 to a great yawn: it was inefficient, slow, and the parameters gave some people the heebie-jeebies. In 2007, Shumow and Ferguson presented at CRYPTO some results that made this design look like it might be backdoored. An algorithm that nobody used in the first place ... remained an algorithm that nobody used in the first place. Six years later the _New York Times_, reporting on alleged internal NSA memos provided by _l'affaire Snowden_, accused the NSA of inserting a back door into the Dual_EC_DRBG standard. But _l'affaire Snowden_ did not reveal the problems in Dual_EC_DRBG. They were already quite well known about in the crypto community. > Then they adjusted the spec as little as possible. This is a flat lie. NIST's official statement can be found at: http://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.pdf "NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A, no longer be used. Effective immediately, NIST Special Publication 800-90A is being re-issued as a draft for public comment for a period ending November 6, 2013. Any concerns or recommendations for improvement regarding the Recommendation for Random Number Generation Using Deterministic Random Bit Generators are solicited." Then, on April 21, 2014, they announced their final decision with respect to Dual_EC_DRBG: http://www.nist.gov/itl/csd/sp800-90-042114.cfm "Following a public comment period and review, the National Institute of Standards and Technology (NIST) has removed a cryptographic algorithm from its draft guidance on random number generators." Dual_EC_DRBG wasn't "adjusted as little as possible". It was outright *removed*. And given how easy this is to find -- seriously, NIST *wants people to know this* -- I find this error of fact pretty much inexcusable. > In our view it's generally better to avoid state sponsored > standards. Who is the "us" that you're referring to? >> From https://goodcrypto.com/qna/technical/dsa-flaws/: From that webpage: "DSA has been compromised." No, it hasn't. So far no one has shown any ability to break even DSA-1024. I'm not optimistic about the long-term health of DSA-1024 (see the archives), but it's flat *wrong* to say that we know DSA-1024 to be compromised. "The SSH spec says 'exactly 1024 bits', not '1024 bits or less.' Why?" Because FIPS 186-2, which OpenSSH wants to track, requires 1024-bit DSA. FIPS 186-3 and 186-4, successors, permit up to 3072-bit DSA. Why isn't OpenSSH tracking FIPS 186-3 and -4? Good question. Probably because the handwriting is on the wall and ECDSA is the future, and limited manpower can be better devoted to getting ECDSA working correctly rather than continuing to track obsolescent DSA standards. > First, why should the whole world be restricted by a U.S. FIPS > (Federal Information Processing Standard)? It's not. However, there are a *lot* of businesses that do trade with the United States government, and these businesses are required to comply with federal information processing standards. If your software doesn't conform to the appropriate FIPS, you won't get the government's business. It's like objecting to the Russian cipher GOST. GOST is a Russian governmental standard. If you want to do business with the Russian government, you need to support GOST. That doesn't mean you're "restricted" to supporting GOST; that means supporting GOST is a good idea for anyone who wants to do business with the Kremlin. > Rainbow tables take a lot of resources to generate. The spec says > "exactly" because that rainbow table is half of the size of a rainbow > table for "1024 bits or less". NSA specified "exactly" 1024 bits to > cut their work in half. This is factually incoherent. Rainbow tables attack hash functions: they don't attack signature algorithms. If someone was interested in using rainbow tables against a signature algorithm they'd make sure to carefully specify what hash algorithm was used, because rainbow tables have to be made specifically for a hash algorithm. But we don't see that in the DSA spec, so the conclusion I draw is that what you're saying here is flat wrong. From wk at gnupg.org Mon Nov 10 19:43:00 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 10 Nov 2014 19:43:00 +0100 Subject: GPG API: Open Crypto Engine In-Reply-To: <20141110171410cQwKOe9HNd@goodcrypto.com> (nan@goodcrypto.com's message of "Mon, 10 Nov 2014 17:14:10 GMT") References: <20141110171410cQwKOe9HNd@goodcrypto.com> Message-ID: <87ioimaocr.fsf@vigenere.g10code.de> On Mon, 10 Nov 2014 18:14, nan at goodcrypto.com said: > No. OCE predates GPGME. Really? From the GPGME NEWS: Noteworthy changes in version 0.2.1 (2001-04-02) ------------------------------------------------ Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Nov 10 19:46:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 13:46:55 -0500 Subject: DSA key sizes In-Reply-To: References: <20141110173434qpTxUGZCgP@goodcrypto.com> Message-ID: <5461081F.3040401@sixdemonbag.org> > DSA 4096, 5120, and 8192 should be available when governments > advocate 3072. The USG does not advocate any particular key size. They've made DSA available in three sizes (as of FIPS 180-something) to support a variety of different needs. > I also find the rainbow table fairly probable. I don't want to sound blunt, but I respectfully suggest you don't understand how rainbow tables work. They aren't used against signature algorithms. They're used against *hash algorithms*. Huge difference. If you have a rainbow table that can break SHA-1 (not that I think one exists today), then it's completely useless against RIPEMD-160 or truncated SHA-256. If anyone wanted to use rainbow tables against DSA-1024, they would need some way to ensure that only one particular hash algorithm could be used with DSA-1024. Instead, DSA-1024 just requires 160 bits of hash. SHA-1, RIPEMD-160, Tiger-192, WHIRLPOOL, SHA-224/160, SHA-256/160, SHA-384/160, SHA-512/160... Or, if you already believe some shadowy and nefarious organization has rainbow tables for SHA-1, then I guess you could just say "I believe the shadowy and nefarious conspiracy has at least eight times the resources it did before, and it has rainbow tables for *everything*." But at that point you've got a problem: if you're positing that your opponent has such unlimited computational resources that they're in effect God, well ... you don't win against God. You've just defined the opposition as having such unlimited computational resources that nothing you do will matter and nothing you do can possibly save you. > Given the recent demonstration of an md5 break for less than a dollar > on s3 gpu nodes, I'd not be surprised to see it in under a year. That's MD5. We knew all the way back in 1997 that MD5 could be broken on a Pentium-90 (that's a 90MHz Pentium, kids: a full tenth of a gigahertz) in under an hour. We knew it because Hans Dobbertin *did it*. (The MD5 attacks have all been attacks on the MD5 compression function, extended out to attacks on the full MD5 hash. In 1997, Hans Dobbertin proved the MD5 compression function was quite a lot weaker than anyone expected and produced collisions in the compression function.) SHA-1 has been shown to have a much weaker compression function than the designers intended. No one has shown any such weaknesses in RIPEMD-160, SHA-224, SHA-256, SHA-384, SHA-512, Tiger192, or WHIRLPOOL. From rjh at sixdemonbag.org Mon Nov 10 19:51:29 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 13:51:29 -0500 Subject: DSA key sizes In-Reply-To: <54610468.3060005@sixdemonbag.org> References: <20141110173434qpTxUGZCgP@goodcrypto.com> <54610468.3060005@sixdemonbag.org> Message-ID: <54610931.2010801@sixdemonbag.org> > And given how easy this is to find -- seriously, NIST *wants people > to know this* -- I find this error of fact pretty much inexcusable. ObDisclosure: I work with NIST maintaining some software connected to the National Software Reference Library. I am not a NIST employee; I've never taken a paycheck from NIST; I just work on an open-source project to help people use the NSRL. http://www.nsrl.nist.gov From aarcane at aarcane.org Mon Nov 10 20:01:53 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Mon, 10 Nov 2014 11:01:53 -0800 Subject: DSA key sizes In-Reply-To: <5461081F.3040401@sixdemonbag.org> References: <20141110173434qpTxUGZCgP@goodcrypto.com> <5461081F.3040401@sixdemonbag.org> Message-ID: On Nov 10, 2014 10:48 AM, "Robert J. Hansen" wrote: >> >> DSA 4096, 5120, and 8192 should be available when governments >> advocate 3072. > > > The USG does not advocate any particular key size. They've made DSA > available in three sizes (as of FIPS 180-something) to support a variety > of different needs. > > >> I also find the rainbow table fairly probable. > > > I don't want to sound blunt, but I respectfully suggest you don't > understand how rainbow tables work. > > They aren't used against signature algorithms. They're used against > *hash algorithms*. Huge difference. If you have a rainbow table that > can break SHA-1 (not that I think one exists today), then it's > completely useless against RIPEMD-160 or truncated SHA-256. > > If anyone wanted to use rainbow tables against DSA-1024, they would need > some way to ensure that only one particular hash algorithm could be used > with DSA-1024. Instead, DSA-1024 just requires 160 bits of hash. > SHA-1, RIPEMD-160, Tiger-192, WHIRLPOOL, SHA-224/160, SHA-256/160, > SHA-384/160, SHA-512/160... I'm proposing, or supporting the hypothesis at least, that a government agency has a rainbow table mapping one dsa public key to the corresponding private key, and vice versa. Given the amount of time and the amount of resources at their disposal, it's not that improbable for a 1024 bit keysize. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Nov 10 20:08:41 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 14:08:41 -0500 Subject: DSA key sizes In-Reply-To: <54610468.3060005@sixdemonbag.org> References: <20141110173434qpTxUGZCgP@goodcrypto.com> <54610468.3060005@sixdemonbag.org> Message-ID: <54610D39.5030203@sixdemonbag.org> Last addendum, I promise: > This is factually incoherent. Rainbow tables attack hash functions: > they don't attack signature algorithms. If someone was interested > in using rainbow tables against a signature algorithm they'd make > sure to carefully specify what hash algorithm was used, because > rainbow tables have to be made specifically for a hash algorithm. A question got raised: "Wouldn't this give you a random message that the signature would also work for? Could it even be used to forge a useful message?" First question: yes. Second question: probably not. Maybe, depending on how the signature was being used. There are good reasons why nobody attacks signatures with rainbow tables. I apologize for not making this clear in my earlier email -- I thought it went without saying, but maybe the clarification is useful. From rjh at sixdemonbag.org Mon Nov 10 20:10:13 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 14:10:13 -0500 Subject: DSA key sizes In-Reply-To: References: <20141110173434qpTxUGZCgP@goodcrypto.com> <5461081F.3040401@sixdemonbag.org> Message-ID: <54610D95.2040609@sixdemonbag.org> > I'm proposing, or supporting the hypothesis at least, that a > government agency has a rainbow table mapping one dsa public key to > the corresponding private key, and vice versa. Given the amount of > time and the amount of resources at their disposal, it's not that > improbable for a 1024 bit keysize. (a) that's not a rainbow table (b) that's a table about a hellabyte in size One hellabyte is about 50,000 times the total informational content generated by the entire human race over the whole of our existence, by the way. From nan at goodcrypto.com Mon Nov 10 20:23:53 2014 From: nan at goodcrypto.com (Nan) Date: Mon, 10 Nov 2014 19:23:53 GMT Subject: GPG API: Open Crypto Engine Message-ID: <20141110192353y6wVN9roTr@goodcrypto.com> >>nan at goodcrypto.com wrote: >>No. OCE predates GPGME. >wk at gnupg.org replied: >Really? From the GPGME NEWS: >Noteworthy changes in version 0.2.1 (2001-04-02) The software that included OCE was also started in early 2001. Werner, since I don't remember the month you could certainly be right. We knew and trusted GPG and hadn't heard of GPGME. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From dkg at fifthhorseman.net Mon Nov 10 20:25:12 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 10 Nov 2014 09:25:12 -1000 Subject: DSA key sizes In-Reply-To: <54610468.3060005@sixdemonbag.org> References: <20141110173434qpTxUGZCgP@goodcrypto.com> <54610468.3060005@sixdemonbag.org> Message-ID: <54611118.2090805@fifthhorseman.net> On 11/10/2014 08:31 AM, Robert J. Hansen wrote: > What Nan means to be talking about is the Dual Elliptical Curve > Deterministic Random Bit Generator (Dual_EC_DRBG) specification -- a way > of generating random numbers, but *not* a signature algorithm. It was > released in 2004 to a great yawn: it was inefficient, slow, and the > parameters gave some people the heebie-jeebies. In 2007, Shumow and > Ferguson presented at CRYPTO some results that made this design look > like it might be backdoored. > > An algorithm that nobody used in the first place ... remained an > algorithm that nobody used in the first place. Nobody may have used Dual_EC_DRBG "in the first place" (since of course it didn't exist before it was proposed), but that doesn't mean that nobody used it. Despite its terrible performance, RSA's BSAFE library used Dual_EC_DRBG as the default CSPRNG for 9 years (most of them well after Shumow and Ferguson's results), removing it only in 2013 when forced to by leaked documents confirming the backdoor: https://en.wikipedia.org/wiki/RSA_BSAFE#Dual_EC_DRBG_backdoor http://www.reuters.com/article/2013/12/20/us-usa-security-rsa-idUSBRE9BJ1C220131220 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Nov 10 20:36:01 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 14:36:01 -0500 Subject: DSA key sizes In-Reply-To: <54611118.2090805@fifthhorseman.net> References: <20141110173434qpTxUGZCgP@goodcrypto.com> <54610468.3060005@sixdemonbag.org> <54611118.2090805@fifthhorseman.net> Message-ID: <546113A1.8070305@sixdemonbag.org> > Nobody may have used Dual_EC_DRBG "in the first place" (since of > course it didn't exist before it was proposed), but that doesn't > mean that nobody used it. "in the first place" meaning "since it was proposed in 2004". > Despite its terrible performance, RSA's BSAFE library used > Dual_EC_DRBG as the default CSPRNG for 9 years (most of them well > after Shumow and Ferguson's results), removing it only in 2013 when > forced to by leaked documents confirming the backdoor: Yes, but strangely, despite the fact OpenSSL's Dual_EC_DRBG support never worked outside of the test harness, nobody ever filed a ticket against OpenSSL demanding Dual_EC_DRBG be fixed. BSAFE may have used it by default (much to RSA's shame, and they deserve to spend a long, long time living it down), but BSAFE isn't anywhere near as big of a player in the market as OpenSSL is. The two biggest players in that area are Microsoft, which supported it but not by default, and OpenSSL. But I agree, saying that "nobody used it" was going a little far. I think it's accurate to say very few people used it. From rjh at sixdemonbag.org Mon Nov 10 20:41:19 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 14:41:19 -0500 Subject: DSA key sizes In-Reply-To: <54610D95.2040609@sixdemonbag.org> References: <20141110173434qpTxUGZCgP@goodcrypto.com> <5461081F.3040401@sixdemonbag.org> <54610D95.2040609@sixdemonbag.org> Message-ID: <546114DF.6000509@sixdemonbag.org> > (b) that's a table about a hellabyte in size Whoops, my bad. Sorry. That table would have more entries than there are atoms in the universe -- by an extremely large margin. From jens at jensl.se Mon Nov 10 20:47:51 2014 From: jens at jensl.se (Jens Lind) Date: Mon, 10 Nov 2014 20:47:51 +0100 (CET) Subject: Gemalto pinpad not working Message-ID: Hello! I can't get the pinpad on GemPC pinpad reader working. I followed this guide: http://wiki.gnupg.org/CardReader/GemaltoPC But unable to get it to work. The display is just blank. My login data looks like this: Login data .......: myuser\n^TP=6,8\n Any ideas on how to get it working? Running GnuPG 2.0.26 on OS X 10.10 Best regards Jens From rjh at sixdemonbag.org Tue Nov 11 00:29:23 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 10 Nov 2014 18:29:23 -0500 Subject: ECDSA vs EDDSA In-Reply-To: References: Message-ID: <54614A53.2050200@sixdemonbag.org> > Perhaps someone who knows about EC could write an FAQ on the wiki for > those of us who are confused by all the new options? Workin' on it. From sinic at sinic.name Tue Nov 11 00:51:19 2014 From: sinic at sinic.name (Simon Nicolussi) Date: Tue, 11 Nov 2014 00:51:19 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <20141107212101.GA14502@blues.local.sinic.name> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> Message-ID: <20141110235119.GA13995@blues.local.sinic.name> I wrote: > I've attached an exemplary signature file (named gnupg-2.1.0.tar.bz2.sig > for your convenience) that demonstrates the problem: Addendum: I noticed that GnuPG releases and git tags are signed with the same key. Abusing the latter, I'm able to generate far smaller signature files. The date is now also correct (although the time is still off): > $ echo evil stuff > gnupg-2.1.0.tar.bz2 > $ gpg2 --verify gnupg-2.1.0.tar.bz2.sig > gpg: Signature made Wed Nov 5 15:30:17 2014 CET using RSA key ID 4F25E3B6 > gpg: Good signature from "Werner Koch (dist sig)" [full] As the generated signature file was even smaller than the original one, I padded it to full length with a private/experimental packet (tag 60): > $ wc -c gnupg-2.1.0.tar.bz2.sig{,.orig} > 861 gnupg-2.1.0.tar.bz2.sig > 861 gnupg-2.1.0.tar.bz2.sig.orig -- Simon Nicolussi http{s,}://{www.,}sinic.name/ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.1.0.tar.bz2.sig Type: application/octet-stream Size: 861 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From nicholas.cole at gmail.com Tue Nov 11 07:38:28 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 11 Nov 2014 06:38:28 +0000 Subject: Detached signature ambiguity In-Reply-To: <5460AED1.1020509@digitalbrains.com> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <5460A893.6090904@digitalbrains.com> <5460AED1.1020509@digitalbrains.com> Message-ID: On Mon, Nov 10, 2014 at 12:25 PM, Peter Lebbing wrote: > On 10/11/14 13:03, Nicholas Cole wrote: >> But in fact, it is the fact that scripts depend on this that made me >> think that this might be a case where things *should* get broken, >> because this is actually a serious security flaw, and the scripts in >> question need fixing. In many cases, no one is going to be around to >> read the warning you suggest. > > Hmmm, very solid point... unfortunately :(. Not a pretty situation to be > in at all... > > It still suggests to me it should only break when normally there would > be a detached signature verified (i.e., without the .sig extension) but > it is not because it is not a detached signature. I suppose these > scripts wouldn't work anyway when files are named as in my problematic > example: > > gnupg_2.1.0.tar.bz2 > gnupg-2.1.0.tar.bz2.sig > > So simply returning error in the case where there /is/ a full match > seems to fix the scripting case. It still leaves the user-driven case, > because the user can still be foiled by a single-character change. > > It might be possible for an attacker to force a signature verification > failure of a script if he can name files in the same directory. Suppose > a script is supposed to verify ledger.csv.asc, which is /not/ a detached > signature, but simply has the data embedded. An attacker could create a > file in the same dir with the name ledger.csv and cause the ambiguity > detecting mechanism to trigger falsely, leading to signature > verification failure. Whether this is a real issue, I don't know. In my view, the long experience of bugs like this suggests that it is better to live with the short-term pain of breaking things in order to get a robust solution, than to fix a solution in various ingenious ways that themselves introduce a whole series of corner-cases and opportunities for exploitation. I hate breaking backwards compatibility normally, but this seems like such a fundamental problem I don't know what to do about it. I *suppose* a fix would be to: - introduce two new commands along the lines I suggested. - make the old verify command: 1. Refuse to verify a detached signature without a .sig extension 2. Refuse to verify a non-detached-signature contained in a file with a .sig extension. But I don't like the solution, really. It introduces code that has to be maintained, and sill leaves users vulnerable to tricks involving unicode etc., so that the security it provides is itself an illusion. In my view it is much better just to break the old --verify command completely. Scripts that are maintained will have a simple fix, and scripts that are not will no longer give a completely false sense of security. Nicholas From wk at gnupg.org Tue Nov 11 09:52:44 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 09:52:44 +0100 Subject: Detached signature ambiguity In-Reply-To: <5460A893.6090904@digitalbrains.com> (Peter Lebbing's message of "Mon, 10 Nov 2014 12:59:15 +0100") References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <5460A893.6090904@digitalbrains.com> Message-ID: <87ioim86g3.fsf@vigenere.g10code.de> On Mon, 10 Nov 2014 12:59, peter at digitalbrains.com said: > If GnuPG encounters this situation, but file.ext.sig is not a detached > signature, it could display a big fat warning: > > WARNING: file.ext.sig is NOT a detached signature; the file file.ext is > NOT VERIFIED! I think this is what I will implement. In addition verifying a detached signature in --batch mode will required that both files are given and fail otherwise. After all the mode where gpg figures out the data file is a convenience feature which is indicated by gpg: assuming signed data in 'FILE' in --verbose mode. This will break scripts using the abbreviated command line version but it is better they break for a valid signature than accepting faked signatures. Note that this bug also affects gpgv. > This does create some related issues: > > gnupg_2.1.0.tar.bz2 > gnupg-2.1.0.tar.bz2.sig That is an entire different thing and not a problem of gpg. You have the very same problem with all tools and URLs. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 11 10:18:37 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 10:18:37 +0100 Subject: Clang with GnuPG 2.1.0 In-Reply-To: <545D152F.3040806@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 07 Nov 2014 13:53:35 -0500") References: <545D152F.3040806@sixdemonbag.org> Message-ID: <87egta858y.fsf@vigenere.g10code.de> On Fri, 7 Nov 2014 19:53, rjh at sixdemonbag.org said: > In file included from /usr/include/netinet/in.h:22: > In file included from ../gl/stdint.h:83: That file is the cause of a lot of evil. gnulib is simply to complex to use only a small part of it and neglect to update it with each release. Not updating the gnulib code is actually on purpose because it has been the cause of many regressions. I have meanwhile remove the gnulib code but need to add two or 3 specific replacement functions which are the only reason gnulib was used. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 11 10:28:44 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 10:28:44 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: ("Ville =?utf-8?B?TcOkw6R0dMOkIidz?= message of "Thu, 6 Nov 2014 16:22:36 +0200") References: <87ioisn1mo.fsf@vigenere.g10code.de> <87sihwju93.fsf@vigenere.g10code.de> Message-ID: <8761em84s3.fsf@vigenere.g10code.de> Hi, On Thu, 6 Nov 2014 15:22, mailing-lists at asatiifm.net said: >> gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include ! >> -I/usr/local/Cellar/libgpg-error/1.13/include >> -I/usr/local/Cellar/libassuan/2.1.2/include ! >> -I/usr/local/Cellar/libgpg-error/1.13/include >> -I/usr/local/Cellar/libksba/1.3.1/include ! >> -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall >> -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o >> libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib ! >> -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error >> -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan ! >> -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error ! >> -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv I do not known your build setup, but how did you manage to include 2 different versions of libgpg-error - something most be broken in your setup. Custom CFLAGS set? A messed up stow(1) tree? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Tue Nov 11 11:00:52 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 11 Nov 2014 11:00:52 +0100 Subject: Detached signature ambiguity In-Reply-To: <87ioim86g3.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <5460A893.6090904@digitalbrains.com> <87ioim86g3.fsf@vigenere.g10code.de> Message-ID: <5461DE54.2020508@digitalbrains.com> On 11/11/14 09:52, Werner Koch wrote: > I think this is what I will implement. How would the warning be triggered? By the extension of the signature file or by existence of a file without the .sig extension, or even some other way? > That is an entire different thing and not a problem of gpg. If the warning is triggered by existence of a file without the .sig extension, it does suggest to me that people should not rely on the warning and thus always specify both the signature file and the signed file on the command line. Because they might infer by absence of the warning that the misnamed file has been verified, when the warning is absent because GnuPG never noticed the misnamed file. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Tue Nov 11 12:09:48 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 12:09:48 +0100 Subject: Detached signature ambiguity In-Reply-To: <5461DE54.2020508@digitalbrains.com> (Peter Lebbing's message of "Tue, 11 Nov 2014 11:00:52 +0100") References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <5460A893.6090904@digitalbrains.com> <87ioim86g3.fsf@vigenere.g10code.de> <5461DE54.2020508@digitalbrains.com> Message-ID: <87zjby6lj7.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 11:00, peter at digitalbrains.com said: > How would the warning be triggered? By the extension of the signature > file or by existence of a file without the .sig extension, or even some > other way? Using an extension is in general not a good idea but in this case we use it anyway to determine the matching data file. Thus we will use both. > If the warning is triggered by existence of a file without the .sig > extension, it does suggest to me that people should not rely on the > warning and thus always specify both the signature file and the signed > file on the command line. Because they might infer by absence of the Indeed, this should always be done. I will also make the gpgv: assuming signed data in 'xzy' show up always and not just in verbose mode. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Tue Nov 11 12:56:59 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 11 Nov 2014 11:56:59 +0000 Subject: GnuPG 2.1 Unattended EC Generation In-Reply-To: <87ppcv9ffc.fsf@vigenere.g10code.de> References: <87ppcv9ffc.fsf@vigenere.g10code.de> Message-ID: On Mon, Nov 10, 2014 at 4:41 PM, Werner Koch wrote: > On Mon, 10 Nov 2014 12:52, nicholas.cole at gmail.com said: > >> How does unattended generation of elliptic curve keys work? As far as >> I can see, that section of the manual has not been updated for the new >> EC options, but I presume that it has to work slightly differently. >> Am I right that key-length is now a no-op? And how do you specify the > > Right, you need to use "Key-Curve" or "Subkey-Curve". Curve names are > as supported by Libgcrypt, for example: "nistp256" or "ed25519". Thanks Werner! Two smaller problems. Under previous versions, failing to provide a Passphrase: would create a key without a passphrase. This was useful for testing purposes. Is that still possible? In version 2.1, if no password is specified, gpg2 tries to call pin-entry and ask for a passphrase. The second problem is that if gpg is called with a non-standard --homedir the whole thing fails with: gpg: agent_genkey failed: No pinentry gpg: key generation failed: No pinentry I'm sure this means that I'm invoking the new gpg2 and gpg-agent combination incorrectly. Sorry for all the flood of questions. gpg2 "modern" is very exciting, but getting all the pieces to work as they used to (and making changes for the new system) is going to take a bit of time! Best wishes, N From wk at gnupg.org Tue Nov 11 14:27:54 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 14:27:54 +0100 Subject: GnuPG 2.1 Unattended EC Generation In-Reply-To: (Nicholas Cole's message of "Tue, 11 Nov 2014 11:56:59 +0000") References: <87ppcv9ffc.fsf@vigenere.g10code.de> Message-ID: <87vbml7tph.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 12:56, nicholas.cole at gmail.com said: > Is that still possible? In version 2.1, if no password is specified, > gpg2 tries to call pin-entry and ask for a passphrase. A quick look into the manual (for me the source, but you may want to use the online version) gives: @item %no-protection Since GnuPG version 2.1 it is not anymore possible to specify a passphrase for unattended key generation. The passphrase command is simply ignored and @samp{%ask-passpharse} is thus implicitly enabled. Using this option allows the creation of keys without any passphrase protection. This option is mainly intended for regression tests. Thus by adding %no-protection to the parameter files you can create a key without a passphrase. > The second problem is that if gpg is called with a non-standard > --homedir the whole thing fails with: > > gpg: agent_genkey failed: No pinentry Install a pinentry. I guess you put usually have a "pinentry-program" line in your gpg-agent.conf. With a different home directory the gpg-agent.conf of that home directory is used. I suggest to install a symlink to pinentry into the installation dir of gnupg and not to use "pinentry-program". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Tue Nov 11 14:32:32 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 11 Nov 2014 13:32:32 +0000 Subject: GnuPG 2.1 Unattended EC Generation In-Reply-To: <87vbml7tph.fsf@vigenere.g10code.de> References: <87ppcv9ffc.fsf@vigenere.g10code.de> <87vbml7tph.fsf@vigenere.g10code.de> Message-ID: I'm so sorry, Werner. I thought I'd checked the manual. Huge apologies. On Tuesday, 11 November 2014, Werner Koch wrote: > On Tue, 11 Nov 2014 12:56, nicholas.cole at gmail.com said: > > > Is that still possible? In version 2.1, if no password is specified, > > gpg2 tries to call pin-entry and ask for a passphrase. > > A quick look into the manual (for me the source, but you may want to use > the online version) gives: > > @item %no-protection > Since GnuPG version 2.1 it is not anymore possible to specify a > passphrase for unattended key generation. The passphrase command is > simply ignored and @samp{%ask-passpharse} is thus implicitly enabled. > Using this option allows the creation of keys without any passphrase > protection. This option is mainly intended for regression tests. > > Thus by adding > > %no-protection > > to the parameter files you can create a key without a passphrase. > > > The second problem is that if gpg is called with a non-standard > > --homedir the whole thing fails with: > > > > gpg: agent_genkey failed: No pinentry > > Install a pinentry. I guess you put usually have a > "pinentry-program" line in your gpg-agent.conf. With a different home > directory the gpg-agent.conf of that home directory is used. I suggest > to install a symlink to pinentry into the installation dir of gnupg and > not to use "pinentry-program". > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue Nov 11 15:21:07 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 11 Nov 2014 15:21:07 +0100 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME Message-ID: <201411111521.21557.bernhard@intevation.de> In https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html the Mailpile developers would like to replace GnuPG with something better and for the short term propose to extend GnuPG with a command line JSON interface in the short term. I've commented the article under the LWN news about GnuPG 2.1.0 release https://lwn.net/Articles/619337/ as following: "If Sm?ri's thoughts on GnuPG reveal something, it is that we need to spread more knowledge about how GnuPG works. In the post, the supported API of GnuPG, GPGME is miss-spelled and the current python libaries for interacting with it were not identified. http://wiki.gnupg.org/APIs shows that pyme has moved to a new location with 0.9 published on May 2014 and the alternative pygpgme's 0.3 is from 2012. There is example code which is nice to work with. Of course the command line interface is not the best stable interface to program GnuPG, it is because it is used as an interface to humans using the command line. GPGME is much better, of course it can be improved further. Yes, Werner and his company g10code need your support, see http://g10code.com/index.html#sec-1-1 . (Full disclosure: My company Intevation is a business partner of g10code.)" Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From mailing-lists at asatiifm.net Tue Nov 11 15:59:00 2014 From: mailing-lists at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Tue, 11 Nov 2014 16:59:00 +0200 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <8761em84s3.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87sihwju93.fsf@vigenere.g10code.de> <8761em84s3.fsf@vigenere.g10code.de> Message-ID: <41FE0265-6445-4028-9455-32918728C5FD@asatiifm.net> Hi, That?s somehow just the result of running ./configure. Running a fresh (fresh untarred source, no speedo runs) configure reported this for me: ? configure: checking for libraries checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.15... yes (1.17) checking for libgcrypt-config... ? That?s a homebrew installed /usr/local/Cellar/libgpg-error/1.17. I don?t have CFLAGS set to anything. Mac OS X 10.9 and using homebrew for most things. The only thing I do is run ./configure && make in the untarred gnupg-2.1.0. I wouldn?t be surprised if there?s something special in the system but I?m not consciously doing anything other that the usual make routine. I also just did a fresh run of speedo.mk and in that case got the same error as Nicholas originally reported (?_default_errsource?). -- Ville On 11 Nov 2014, at 11:28, Werner Koch wrote: > Hi, > > On Thu, 6 Nov 2014 15:22, mailing-lists at asatiifm.net said: > >>> gcc -I/usr/local/Cellar/libgcrypt/1.6.2/include > ! >> -I/usr/local/Cellar/libgpg-error/1.13/include >>> -I/usr/local/Cellar/libassuan/2.1.2/include > ! >> -I/usr/local/Cellar/libgpg-error/1.13/include >>> -I/usr/local/Cellar/libksba/1.3.1/include > ! >> -I/usr/local/Cellar/libgpg-error/1.16/include -g -O2 -Wall >>> -Wno-pointer-sign -Wpointer-arith -o t-sexputil t-sexputil.o >>> libcommon.a ../gl/libgnu.a -L/usr/local/Cellar/libgcrypt/1.6.2/lib > ! >> -lgcrypt -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error >>> -L/usr/local/Cellar/libassuan/2.1.2/lib -lassuan > ! >> -L/usr/local/Cellar/libgpg-error/1.13/lib -lgpg-error > ! >> -L/usr/local/Cellar/libgpg-error/1.17/lib -lgpg-error -liconv > > I do not known your build setup, but how did you manage to include 2 > different versions of libgpg-error - something most be broken in your > setup. Custom CFLAGS set? A messed up stow(1) tree? > > > Shalom-Salam, > > Werner > > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From matt at monaco.cx Tue Nov 11 18:35:17 2014 From: matt at monaco.cx (Matthew Monaco) Date: Tue, 11 Nov 2014 10:35:17 -0700 Subject: SSH generic socket forwarding for gpg-agent Message-ID: <546248D5.9050509@monaco.cx> Does anyone have gpg-agent forwarding working with SSH's recent generic socket forwarding? Does it still require socat on one end, because I've only been able to specify a socket path on the left-hand side of the forwarding specification. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: OpenPGP digital signature URL: From Mustrum at Mustrum.net Tue Nov 11 15:12:17 2014 From: Mustrum at Mustrum.net (Mustrum) Date: Tue, 11 Nov 2014 15:12:17 +0100 Subject: GnuPG 2.1.0 Merging secret key Message-ID: <54621941.5040103@Mustrum.net> Hi all, I'm merging one of my 'old' sub-key into another key-pair. It kept the same keygrip but got a new ID/fingerprint. How can I use that new subkey to decrypt something encrypted to my 'old' subkey ? Regards From wk at gnupg.org Tue Nov 11 20:04:11 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 20:04:11 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <41FE0265-6445-4028-9455-32918728C5FD@asatiifm.net> ("Ville =?utf-8?B?TcOkw6R0dMOkIidz?= message of "Tue, 11 Nov 2014 16:59:00 +0200") References: <87ioisn1mo.fsf@vigenere.g10code.de> <87sihwju93.fsf@vigenere.g10code.de> <8761em84s3.fsf@vigenere.g10code.de> <41FE0265-6445-4028-9455-32918728C5FD@asatiifm.net> Message-ID: <87d28t7e50.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 15:59, mailing-lists at asatiifm.net said: > I don?t have CFLAGS set to anything. Mac OS X 10.9 and using homebrew > for most things. The only thing I do is run ./configure && make in the > untarred gnupg-2.1.0. I wouldn?t be surprised if there?s something I don't know any details about homebrew but it seems to install software in versioned directories. I guess it is missing a dependency tracker and thus when installing Libgcrypt an older (but sufficient) version of libgpg-error gets installed alongside. GnuPG does not pick up that one but a different installation of libgpg-error and thus you run into these problems. May some someone with more OS X experience look at the problem? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 11 20:09:05 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 11 Nov 2014 20:09:05 +0100 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <201411111521.21557.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 11 Nov 2014 15:21:07 +0100") References: <201411111521.21557.bernhard@intevation.de> Message-ID: <878ujh7dwu.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 15:21, bernhard at intevation.de said: > In https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html > the Mailpile developers would like to replace GnuPG with something better > and for the short term propose to extend GnuPG with a command line JSON I have a reply in the works but there are more important tasks right now. JSON seems to be the new standard of the year (it is actually far easier to work with - the C parser/builder I use as has a mere 1300 lines). I don't like to play catch-up with the current whatever data presentation standard. But if someone likes to do that: it is pretty easy to add an JSON interface to gpgme-tool as an alternative to the XML output. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailing-lists at asatiifm.net Tue Nov 11 21:00:26 2014 From: mailing-lists at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Tue, 11 Nov 2014 22:00:26 +0200 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <87d28t7e50.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87sihwju93.fsf@vigenere.g10code.de> <8761em84s3.fsf@vigenere.g10code.de> <41FE0265-6445-4028-9455-32918728C5FD@asatiifm.net> <87d28t7e50.fsf@vigenere.g10code.de> Message-ID: <68A52250-89B0-41AA-A1E2-53172B107096@asatiifm.net> No worries on my part. > it seems to install software in versioned directories. Exactly, under /usr/local? and without messing with the system installed binaries or libraries. Some things, like openssl libraries, it will not link automatically to avoid some issues with system provided libraries, but most things are then symlinked to the usual places to provide the brew installed binaries, etc. > I guess it is missing a dependency tracker and > thus when installing Libgcrypt an older (but sufficient) version of > libgpg-error gets installed alongside. It actually tracks dependencies very well? for anything installed and built with Homebrew. It?s a bit like speedo.mk for everything, or the missing apt-get for Mac, some things are ?bottled? binaries, some things it?ll build for you, in any case pulling any dependencies as needed. In this case when trying to build a tarred source brew is not in the picture at all and all dependency handling is manual / left for the source configure scripts. And things don?t quite work although the configure script gives an OK on the pre-make checklist. I really have no rush with this. Just debugging for others and happily using the stable branch. I can dig into this myself at some point. It?s also possible whoever is maintaining the homebrew repo for gnupg might solve the issue and push an update there. -- Ville On 11 Nov 2014, at 21:04, Werner Koch wrote: > On Tue, 11 Nov 2014 15:59, mailing-lists at asatiifm.net said: > >> I don?t have CFLAGS set to anything. Mac OS X 10.9 and using homebrew >> for most things. The only thing I do is run ./configure && make in the >> untarred gnupg-2.1.0. I wouldn?t be surprised if there?s something > > I don't know any details about homebrew but it seems to install software > in versioned directories. I guess it is missing a dependency tracker and > thus when installing Libgcrypt an older (but sufficient) version of > libgpg-error gets installed alongside. GnuPG does not pick up that one > but a different installation of libgpg-error and thus you run into these > problems. > > May some someone with more OS X experience look at the problem? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From MichaelQuigley at TheWay.Org Tue Nov 11 23:05:26 2014 From: MichaelQuigley at TheWay.Org (MichaelQuigley at TheWay.Org) Date: Tue, 11 Nov 2014 17:05:26 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: References: Message-ID: "Gnupg-users" wrote on 11/08/2014 12:54:30 PM: > ----- Message from Werner Koch on Fri, 07 Nov 2014 > 17:32:49 +0100 ----- > > To: > > "Robert J. Hansen" > > cc: > > gnupg-users at gnupg.org > > Subject: > > Re: GPG 2.1.0/Win32: keyserver lookup problems > > On Thu, 6 Nov 2014 20:09, rjh at sixdemonbag.org said: > > > getting all different kinds of weird errors, from the keyserver helper > > not being able to communicate with the outside world, to GnuPG > > Well, there are no more keyserver helpers. All is done by dirmngr. > > > swearing it's created output but no output file being created (!!), to > > Hmmm, I can't see that. > If your system is trying to write to the Program Files directory, look in the VirtualStore. This can be found at C:\Users\{YourUserID}\AppData\Local\VirtualStore I've been bit by several applications where files end up there instead of the original location. I forget, but I think this feature was introduced in Vista--don't hold me to that. > > (The "GnuPG insists it's created output, but none exists" -- this one > > was so surreal that I was seriously considering whether I was > > Sorry, I can't replicate that. Well, with the fixed version but I > didn't touched anything relevant in gpg.exe. > Again, check for the results in VirtualStore. > > So I repeated the same command line. This time, GnuPG told me the > > file foo.asc already existed, and did I want to overwrite it? > > Is that some weird Windows symlink setup? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.toponce at gmail.com Tue Nov 11 23:41:55 2014 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Tue, 11 Nov 2014 15:41:55 -0700 Subject: Tweeting for GnuPG In-Reply-To: <874mudo0ud.fsf@vigenere.g10code.de> References: <874mudo0ud.fsf@vigenere.g10code.de> Message-ID: <20141111224153.GI8185@irc.ae7.st> On Wed, Nov 05, 2014 at 09:21:14PM +0100, Werner Koch wrote: > I am looking for one or two people who would like to fill the @gnupg > Twitter account with some life. > > I am not one of those short message people but Twitter seems to be a big > deal these days. Thus if someone would be interested to post short > stuff there on a regular base we can arrange for it. We have 1400 > followers right now. Anyone? If there is still need for this, I don't mind stepping in. Most of my personal tweets belong in the crypto topic. So long as guidelines and expectations are established on what should be tweeted and when, I could probably fill this role. FYI. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 502 bytes Desc: not available URL: From aranea at aixah.de Tue Nov 11 23:49:20 2014 From: aranea at aixah.de (Luis Ressel) Date: Tue, 11 Nov 2014 23:49:20 +0100 Subject: GnuPG 2.1.0: --refresh-keys regression Message-ID: <20141111234920.06bff9e0@gentp.lnet> Hello, One of the changes introduced with GnuPG 2.1 -- namely, using dirmngr for key retrieval -- has caused some problems for me. First of all, I'm not able to use gpg --refresh-keys anymore, as dirmngr requests all of the keys from the keyserver at once, instead of one-by-one as GnuPG 2.0 did. For keyrings with more than approx. 70 keys, the keyserver (sks-keyservers.net) denies the request, thereby causing the error gpg: keyserver refresh failed: Too many objects and failure to receive any key updates. I assume keymngr should handle this in a better way (or is it wrong for the keyservers to deny such requests?) dirmngr also seems to have problems with hkps certificate checking for keyserver addresses with round-robin DNS, but I need to examine this further before I can provide details. Regards, Luis Ressel -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD From wk at gnupg.org Wed Nov 12 10:30:47 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Nov 2014 10:30:47 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released In-Reply-To: <68A52250-89B0-41AA-A1E2-53172B107096@asatiifm.net> ("Ville =?utf-8?B?TcOkw6R0dMOkIidz?= message of "Tue, 11 Nov 2014 22:00:26 +0200") References: <87ioisn1mo.fsf@vigenere.g10code.de> <87sihwju93.fsf@vigenere.g10code.de> <8761em84s3.fsf@vigenere.g10code.de> <41FE0265-6445-4028-9455-32918728C5FD@asatiifm.net> <87d28t7e50.fsf@vigenere.g10code.de> <68A52250-89B0-41AA-A1E2-53172B107096@asatiifm.net> Message-ID: <87r3x86a0o.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 21:00, mailing-lists at asatiifm.net said: > I really have no rush with this. Just debugging for others and happily using the stable branch. Thanks for explaining. > I can dig into this myself at some point. It?s also possible whoever > is maintaining the homebrew repo for gnupg might solve the issue and > push an update there. It seems that there is a conflict between different build systems. Which is not not surprising. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 12 10:34:33 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Nov 2014 10:34:33 +0100 Subject: GnuPG 2.1.0: --refresh-keys regression In-Reply-To: <20141111234920.06bff9e0@gentp.lnet> (Luis Ressel's message of "Tue, 11 Nov 2014 23:49:20 +0100") References: <20141111234920.06bff9e0@gentp.lnet> Message-ID: <87mw7w69ue.fsf@vigenere.g10code.de> On Tue, 11 Nov 2014 23:49, aranea at aixah.de said: > One of the changes introduced with GnuPG 2.1 -- namely, using dirmngr > for key retrieval -- has caused some problems for me. First of all, I'm Thanks for reporting. I am already aware of it asdkg already reported that a few days ago. > I assume keymngr should handle this in a better way (or is it wrong for > the keyservers to deny such requests?) It is simply a bug. > dirmngr also seems to have problems with hkps certificate checking for > keyserver addresses with round-robin DNS, but I need to examine this > further before I can provide details. Did you put an hkp-cacert FILE into dirmngr.conf ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Wed Nov 12 14:28:05 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 12 Nov 2014 14:28:05 +0100 Subject: ECDSA vs EDDSA In-Reply-To: <87tx279fv0.fsf@vigenere.g10code.de> References: <5460AC86.2000500@digitalbrains.com> <5460CC96.1060001@sumptuouscapital.com> <87tx279fv0.fsf@vigenere.g10code.de> Message-ID: <54636065.7030404@digitalbrains.com> On 10/11/14 17:31, Werner Koch wrote: > Which is used in 2.1: That's great to hear, just like it is in general pretty great you got to release a major new version! Congratulations! After browsing a bit in the source, I conclude that RFC 6979 is used for both classic DSA and ECDSA; something not immediately apparent from the commit message when you don't know the code. After reading parts of the Ed25519 specification[1], given the way they formulate it there, I was left with the impression that ECDSA is necessarily bound to real randomness. I completely forgot that RFC 6979 is cleverly designed to be a drop-in replacement with no changes needed on the receiving side. With Pete Stephenson also rightly calling out my wrong statement on the Brainpool curves, I've come to regret my too hastily written reply. I should have checked my statements. I already had enough doubt to qualify my statement with "and (I believe also) Brainpool". There is enough FUD out there without me adding to that :(. But I'm glad people were quick to point out my factual errors. Thanks! Peter. [1] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. Yang, "High-speed high-security signatures", Journal of Cryptographic Engineering Volume 2, Issue 2, pp. 77-89, September 2011, . PS: Is there a better way to say "classic DSA"? What about "ElGamal-style DSA"? -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed Nov 12 15:12:14 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Nov 2014 15:12:14 +0100 Subject: ECDSA vs EDDSA In-Reply-To: <54636065.7030404@digitalbrains.com> (Peter Lebbing's message of "Wed, 12 Nov 2014 14:28:05 +0100") References: <5460AC86.2000500@digitalbrains.com> <5460CC96.1060001@sumptuouscapital.com> <87tx279fv0.fsf@vigenere.g10code.de> <54636065.7030404@digitalbrains.com> Message-ID: <874mu45wzl.fsf@vigenere.g10code.de> On Wed, 12 Nov 2014 14:28, peter at digitalbrains.com said: > After browsing a bit in the source, I conclude that RFC 6979 is used for > both classic DSA and ECDSA; something not immediately apparent from the > commit message when you don't know the code. Right. And actually it can also be used for 2.0. This requires a runtime check for the libgcrypt version and to add the rfc6979 flag for libgcrypt 1.6. In 2.0 we have use this in g10/pkglue.c: if (gcry_sexp_build (&s_hash, NULL, "%m", hash)) BUG (); /* gcry_sexp_build should never fail. */ it needs to be replaced with something like if (gcry_check_version ("1.6.0") { err = gcry_sexp_build (&hash, NULL, "(data (flags rfc6979) (hash %s %b))", rfc6979_hash_algo_string (mdlen), (int)mdlen, md); } else err = gcry_sexp_build (&s_hash, NULL, "%m", hash); but the callers of that pk_sign function need to provide the hash algorithm as well. Thus more than a few lines need to be changed. it would be useful to have this for plain DSA, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Wed Nov 12 16:42:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 12 Nov 2014 10:42:55 -0500 Subject: GPG 2.1.0/Win32: keyserver lookup problems In-Reply-To: References: Message-ID: <54637FFF.3090408@sixdemonbag.org> > If your system is trying to write to the Program Files directory, look > in the VirtualStore. This can be found at This turned out to be exactly it. Thank you, Michael: this was driving me up the wall and making me wonder if I'd been hallucinating. :) From rjh at sixdemonbag.org Wed Nov 12 17:02:31 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 12 Nov 2014 11:02:31 -0500 Subject: ECDSA vs EDDSA In-Reply-To: <54636065.7030404@digitalbrains.com> References: <5460AC86.2000500@digitalbrains.com> <5460CC96.1060001@sumptuouscapital.com> <87tx279fv0.fsf@vigenere.g10code.de> <54636065.7030404@digitalbrains.com> Message-ID: <54638497.70404@sixdemonbag.org> > There is enough FUD out there without me adding to that :(. Everybody makes a braino sooner or later. God knows I have my own litany of them. :) From shavital at netvision.net.il Wed Nov 12 15:20:21 2014 From: shavital at netvision.net.il (Charly Avital) Date: Wed, 12 Nov 2014 16:20:21 +0200 Subject: Unsubscribing temporarily Message-ID: <54636CA5.6090404@netvision.net.il> Hi, for health reasons I am unsubscribing for the time being. I shall subscribe again in due time. My apologies to the list. From nicholas.cole at gmail.com Wed Nov 12 21:55:10 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 12 Nov 2014 20:55:10 +0000 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <201411111521.21557.bernhard@intevation.de> References: <201411111521.21557.bernhard@intevation.de> Message-ID: On Tue, Nov 11, 2014 at 2:21 PM, Bernhard Reiter wrote: > In https://www.mailpile.is/blog/2014-10-07_Some_Thoughts_on_GnuPG.html > the Mailpile developers would like to replace GnuPG with something better > and for the short term propose to extend GnuPG with a command line JSON > interface in the short term. > > I've commented the article under the LWN news about GnuPG 2.1.0 release > https://lwn.net/Articles/619337/ as following: I actually disagree with the assumption here. The --with-colons --command-fd --status-fd interface has been remarkably stable. The last major incompatible change was in 1.4.9 and 2.0.11 when the order in which subkey algorithms were presented was changed. Other than that, it is an incredibly well-designed an easy to parse interface. The only way in which it can trip you up is that you need to keep a careful watch on whether you are expecting further data from gpg or not. The stability and utility of this interface is one of my favourite aspects of the gnupg project, and I really admire Werner for his work here. Nicholas From 2014-667rhzu3dc-lists-groups at riseup.net Wed Nov 12 23:46:47 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 12 Nov 2014 22:46:47 +0000 Subject: GnuPG 2.1.0 Merging secret key In-Reply-To: <54621941.5040103@Mustrum.net> References: <54621941.5040103@Mustrum.net> Message-ID: <12110120275.20141112224647@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 11 November 2014 at 2:12:17 PM, in , Mustrum wrote: > Hi all, > I'm merging one of my 'old' sub-key into another > key-pair. It kept the same keygrip but got a new > ID/fingerprint. > How can I use that new subkey to decrypt something > encrypted to my 'old' subkey ? My guess would be the option "--try-secret-key name" where "name" might be the subkey's new ID followed by an exclamation mark. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net If you save the world too often, it begins to expect it -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJUY+NqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwDUgIALL9+7vMnaRGI0qryxZylU6W UQYA5cWF8cFCT0ZkWACXSHO+AL4Qi7+06z7f3ktEEy06SraW/c66LHZaGg4lwnBp htYhSwzsDs6PZNiNVW+CMtIBqX3Y3exrHLqTsIGKrNNTemJP2OdFIPJ1vYFqd0KE Fvg098LlPRKhrfNGLr4v6olVNfBFP4Xzp5mYL7WGUMR2ViAG9Ch8loJET6J7yjJt 0zAt0i7pDKrVwx9zzkZfg4mTaaL0nIF/R/zB5Pt3dVFPYXoEc7OEZ5ncjrrYVjT6 IMdzfDM7ST21GadDJgd1tJHnhWcHGu/kF64UmsmzGQ0df4NNZ+6AWYvjWfGaing= =DyUI -----END PGP SIGNATURE----- From tristan.santore at internexusconnect.net Thu Nov 13 00:18:33 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Thu, 13 Nov 2014 00:18:33 +0100 Subject: Unsubscribing temporarily In-Reply-To: <54636CA5.6090404@netvision.net.il> References: <54636CA5.6090404@netvision.net.il> Message-ID: <5463EAC9.3050307@internexusconnect.net> On 12/11/14 15:20, Charly Avital wrote: > Hi, > for health reasons I am unsubscribing for the time being. > I shall subscribe again in due time. > My apologies to the list. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Charly, No need to apologize. Just sign up again when you are better. And, I hope and am convinced, that I can speak for the whole list/team, we wish you all the best and hope you get well soon. All the best. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org From bernhard at intevation.de Thu Nov 13 10:08:45 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 13 Nov 2014 10:08:45 +0100 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: References: <201411111521.21557.bernhard@intevation.de> Message-ID: <201411131008.51030.bernhard@intevation.de> On Wednesday 12 November 2014 at 21:55:10, Nicholas Cole wrote: > ?The --with-colons > --command-fd --status-fd interface has been remarkably stable. True, Werner went a long way to keep it stable. > The stability and utility of this interface is one of my favourite > aspects of the gnupg project, and I really admire Werner for his work > here. Still it is a bit of a pain to keep it this way and a better interface is called for anyway, because this has limitations to build good interface. This is whey we have gpgme for more than 10 years, Werner also did a very good job there. Gpgme needs to get more popular, probably improved along the way, but it also would help to make the crypto-experience with GnuPG a lot better for developers and users alike. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Nov 13 10:11:24 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 13 Nov 2014 10:11:24 +0100 Subject: gnome-keyring problem section in the wiki (Re: gnupg privicy assistant - card manager.) In-Reply-To: <87iol7rglh.fsf@vigenere.g10code.de> References: <1409493657.21352.1@Kingston2> <87iol7rglh.fsf@vigenere.g10code.de> Message-ID: <201411131011.25521.bernhard@intevation.de> On Monday 01 September 2014 at 08:37:45, Werner Koch wrote: > On Sun, 31 Aug 2014 16:00, paul.lewis at quadensemble.com said: > > I'd like to use the card manager function, but whenever I invoke it the > > application returns the error "Error accessing the card", and the > > status bar reports "Checking for card .. " > > I have actually thank you for raising this issue: > > gnome-keyring-daemon[5531]: unrecognized command: SCD > > The problem is that the gnome-keyring-dameon hijacks the inter process > communication (IPC) between gpg and gpg-agent. It implements a very > limited set of commands of gpg-agent but nothing more. Recent versions > of GnuPG detect this and show a warning message or pop-up to tell you > just this. Because I ran into the issue analysing why an gpgsm installation on Ubuntu did not work, I think this warrants a section in the wiki: http://wiki.gnupg.org/PlatformNotes If would be nice if you (all) could help me and GnuPG and look up the problem reports within Ubuntu or Gnome and linke them from there. > Depending on the version of gnome-keyring-daemon, it is possible to > disable the gpg-agent hijacking component. Unfortunately it is hard to > convince the maintainer to disable this mis-features. > > > Otherwise if I run gpg --card-status with a card in the USB card reader > > I get the following: > > You are using gpg 1.4.x which can directly talk to the card. However, > latest card features are not supported by 1.4 but only by GnuPG 2.x. > > See the mail thread starting with this mail for details: > > http://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028689.html > > > I presume, the system is misconfigured is some way. Any one got any > > suggestions? > > You may want to bring this to the attention of your Linux distribution. > The solution could be easy: The gpg-agent component needs to be disabled > when build gnome-keyring-daemon: > > ./configure --disable-gpg-agent > > > Shalom-Salam, > > Werner -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Nov 13 11:54:57 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Nov 2014 11:54:57 +0100 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <201411131008.51030.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 13 Nov 2014 10:08:45 +0100") References: <201411111521.21557.bernhard@intevation.de> <201411131008.51030.bernhard@intevation.de> Message-ID: <87ioij2wvy.fsf@vigenere.g10code.de> On Thu, 13 Nov 2014 10:08, bernhard at intevation.de said: > job there. Gpgme needs to get more popular, probably improved along the way, > but it also would help to make the crypto-experience with GnuPG a lot better > for developers and users alike. Actually I see 88 Debian projects depending on libgpgme11. A good step forwad would be the integration of lnaguage bindings into the gpgme package. That should make it easier to use it from languages other than C, C++ (, and CL). However, someone needs to feel reponsible for such a language binding and try to keep it up to date. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Thu Nov 13 14:54:46 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 13 Nov 2014 14:54:46 +0100 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <87ioij2wvy.fsf@vigenere.g10code.de> References: <201411111521.21557.bernhard@intevation.de> <201411131008.51030.bernhard@intevation.de> <87ioij2wvy.fsf@vigenere.g10code.de> Message-ID: <201411131454.55379.bernhard@intevation.de> On Thursday 13 November 2014 at 11:54:57, Werner Koch wrote: > A good step forwad would be the integration of lnaguage bindings into > the gpgme package. ?That should make it easier to use it from languages > other than C, C++ (, and CL). ? Because of possible dependencies, they should end up in different Debian packages. You are talking the source package I guess? http://wiki.gnupg.org/APIs starts to have an overview about language bindings, help appreciated to complete and maintain the list and possible links to tutorials. > However, someone needs to feel reponsible > for such a language binding and try to keep it up to date. Pyme has a debian package. pygpgme has an Ubuntu package. And there are more. Mostly we need more packagers. :) Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Thu Nov 13 16:02:59 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 13 Nov 2014 10:02:59 -0500 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <87ioij2wvy.fsf@vigenere.g10code.de> References: <201411111521.21557.bernhard@intevation.de> <201411131008.51030.bernhard@intevation.de> <87ioij2wvy.fsf@vigenere.g10code.de> Message-ID: <5464C823.5090304@sixdemonbag.org> > A good step forward would be the integration of language bindings > into the gpgme package. Not to beat a broken drum, but making it easier to use GPGME from a Microsoft environment would also be nice. MSVC++ needs a .lib file for each DLL you're going to link against, and GPGME/Win32 doesn't ship with one. Although workarounds exist (making your own .lib file, dynamically opening the DLL, etc.), it would be nice if GPGME could be released with a .lib file. I'm not particularly keen on Microsoft environments for a lot of reasons. However, they do have 85%-90% marketshare. If our goal is ideological purity, MS should be avoided; if our goal is to provide privacy tools to the most people possible, we need to consider MS environments to be a high priority. > That should make it easier to use it from languages other than C, C++ > (, and CL). However, someone needs to feel responsible for such a > language binding and try to keep it up to date. Given the announcement yesterday from MS about how they're opening up the .NET server stack, I think we might see a resurgence of C# in the UNIX space. I have to say, it'd be really nice to see C# bindings for GPGME. There's already one set of them, gpgme-sharp, but I believe they're unmaintained. From wk at gnupg.org Thu Nov 13 18:01:10 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Nov 2014 18:01:10 +0100 Subject: Detached signature ambiguity In-Reply-To: <20141107212101.GA14502@blues.local.sinic.name> (Simon Nicolussi's message of "Fri, 7 Nov 2014 22:21:01 +0100") References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> Message-ID: <87ppcrujah.fsf_-_@vigenere.g10code.de> On Fri, 7 Nov 2014 22:21, sinic at sinic.name said: > I've attached an exemplary signature file (named gnupg-2.1.0.tar.bz2.sig > for your convenience) that demonstrates the problem: Thanks that was useful for testsing. What I did is: commit 69384568f66a48eff3968bb1714aa13925580e9f (HEAD, refs/heads/wk-master) Author: Werner Koch Date: Thu Nov 13 17:39:31 2014 +0100 gpg: Make the use of "--verify FILE" for detached sigs harder. * g10/openfile.c (open_sigfile): Factor some code out to ... (get_matching_datafile): new function. * g10/plaintext.c (hash_datafiles): Do not try to find matching file in batch mode. * g10/mainproc.c (check_sig_and_print): Print a warning if a possibly matching data file is not used by a standard signatures. -- Allowing to use the abbreviated form for detached signatures is a long standing bug which has only been noticed by the public with the release of 2.1.0. :-( What we do is to remove the ability to check detached signature in --batch using the one file abbreviated mode. This should exhibit problems in scripts which use this insecure practice. We also print a warning if a matching data file exists but was not considered because the detached signature was actually a standard signature: gpgv: Good signature from "Werner Koch (dist sig)" gpgv: WARNING: not a detached signature; \ file 'gnupg-2.1.0.tar.bz2' was NOT verified! We can only print a warning because it is possible that a standard signature is indeed to be verified but by coincidence a file with a matching name is stored alongside the standard signature. Reported-by: Simon Nicolussi (to gnupg-users on Nov 7) Signed-off-by: Werner Koch Now waiting which tools or scripts will break. I checked a few (including dpkg) and they do the Right Thing. Shall this be ported to 2.0 and 1.4 and fixes released? I guess yes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 13 18:17:35 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 13 Nov 2014 18:17:35 +0100 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <5464C823.5090304@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 13 Nov 2014 10:02:59 -0500") References: <201411111521.21557.bernhard@intevation.de> <201411131008.51030.bernhard@intevation.de> <87ioij2wvy.fsf@vigenere.g10code.de> <5464C823.5090304@sixdemonbag.org> Message-ID: <87lhnfuij4.fsf@vigenere.g10code.de> On Thu, 13 Nov 2014 16:02, rjh at sixdemonbag.org said: > Not to beat a broken drum, but making it easier to use GPGME from a > Microsoft environment would also be nice. MSVC++ needs a .lib file for > each DLL you're going to link against, and GPGME/Win32 doesn't ship with Looking at the Gpg4win source I see SetOutPath "$INSTDIR\lib" File /oname=libgpgme.imp "${prefix}/lib/libgpgme.dll.a" File /oname=libgpgme-glib.imp "${prefix}/lib/libgpgme-glib.dll.a" which means that an import file for the DLL is installed. No library for static linking but a DLL is anyway better. Actually I added this on your request: commit c5404abb7cc8c284c2a8184a529fb0fdb82d8b50 Author: Werner Koch Date: Wed Dec 5 10:18:43 2012 +0100 Install development files for the GnuPG related libraries. * src/inst-gpgme.nsi: Install gpgme import lib and header file, * src/inst-libassuan.nsi: Likewise. * src/inst-libgcrypt.nsi: Likewise. * src/inst-libgpg-error.nsi: Likewise. * src/inst-libksba.nsi: Likewise. * src/uninst-gpg4win.nsi: Remove the new files. * src/uninst-gpgme.nsi: Ditto. * src/uninst-libassuan.nsi: Ditto. * src/uninst-libgcrypt.nsi: Ditto. * src/uninst-libgpg-error.nsi: Ditto. * src/uninst-libksba.nsi: Ditto. > ideological purity, MS should be avoided; if our goal is to provide > privacy tools to the most people possible, we need to consider MS > environments to be a high priority. It is and that is why I consider to separate GnuPG proper from Gpg4win and provide a core installer with just the core. This has not yet happened because building a side-by-side assembly needs some more experimenting or help. The next installer for 2.1 should fix the major flaws from the first try and be usable. I will add the dev file too. However, it still carries the Pinentry and GPA which should be removed from the core installer. Di you want to test a beta installer? > Given the announcement yesterday from MS about how they're opening up > the .NET server stack, I think we might see a resurgence of C# in the > UNIX space. I have to say, it'd be really nice to see C# bindings for > GPGME. There's already one set of them, gpgme-sharp, but I believe > they're unmaintained. Any volunteer to maintain one? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Nov 13 18:22:07 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Nov 2014 07:22:07 -1000 Subject: Detached signature ambiguity In-Reply-To: <87ppcrujah.fsf_-_@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <87ppcrujah.fsf_-_@vigenere.g10code.de> Message-ID: <5464E8BF.8080706@fifthhorseman.net> On 11/13/2014 07:01 AM, Werner Koch wrote: > gpg: Make the use of "--verify FILE" for detached sigs harder. thanks for doing this, Werner. > Now waiting which tools or scripts will break. I checked a few > (including dpkg) and they do the Right Thing. i'm glad to hear this. > Shall this be ported to 2.0 and 1.4 and fixes released? I guess yes. yes, please. This is an important security hardening, and it shouldn't depend on which branch people are using. If people have tools that break because of this change, those tools were probably vulnerable to even worse breakage (silent breakage where things they thought were validated weren't actually validated), so this is a valuable fix, even if there's short-term difficulty. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.email Thu Nov 13 20:16:45 2014 From: dougb at dougbarton.email (Doug Barton) Date: Thu, 13 Nov 2014 11:16:45 -0800 Subject: Detached signature ambiguity In-Reply-To: <5464E8BF.8080706@fifthhorseman.net> References: <87ioisn1mo.fsf@vigenere.g10code.de> <20141107212101.GA14502@blues.local.sinic.name> <87ppcrujah.fsf_-_@vigenere.g10code.de> <5464E8BF.8080706@fifthhorseman.net> Message-ID: <5465039D.60002@dougbarton.email> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/13/14 9:22 AM, Daniel Kahn Gillmor wrote: | On 11/13/2014 07:01 AM, Werner Koch wrote: |> gpg: Make the use of "--verify FILE" for detached sigs harder. | | thanks for doing this, Werner. | |> Now waiting which tools or scripts will break. I checked a few |> (including dpkg) and they do the Right Thing. | | i'm glad to hear this. | |> Shall this be ported to 2.0 and 1.4 and fixes released? I guess |> yes. | | yes, please. This is an important security hardening, and it | shouldn't depend on which branch people are using. | | If people have tools that break because of this change, those tools | were probably vulnerable to even worse breakage (silent breakage | where things they thought were validated weren't actually | validated), so this is a valuable fix, even if there's short-term | difficulty. +1 to all of dkg's points. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUZQOdAAoJEFzGhvEaGryE8csIAILZzFlDXwELtfN7OHUXLqTZ 5H6Zzebx5c+DcxsF/7Yks/jzPUQ+AnMCWE52DEuRSQTPTRAhTei+sWueNlF2b/1h Yh6WwfLONtoX+Axk7crgjGkHANJaLN/tb7EllNxUsTOtHK84T7k2X5wf8acmgW0a L0C9pXQ/piK7XZCMB0wuqcjaShdorD0GRUne+5h5+p3KHP4eb8qSYfORdL10l/lk fu3/4ARGqIf1rIIEFQc2OP5KX+ElD3K84SX1ff915S07bdPlTnYTKZUWxmqROgOw UP96HjHdSwVXmo50hizozzfHj4S59tq1ttmes0YUe3E+eDhieg7/wqTqEm5Xwi4= =dT7B -----END PGP SIGNATURE----- From wolfgang at roembden.net Thu Nov 13 11:46:37 2014 From: wolfgang at roembden.net (Wolfgang Frisch) Date: Thu, 13 Nov 2014 11:46:37 +0100 Subject: gpg4usb: Portable GUI for GnuPG Message-ID: <54648C0D.6000307@roembden.net> Please consider adding gpg4usb to the GnuPG website. https://www.gnupg.org/related_software/frontends.html >gpg4usb is a very easy to use and small portable editor to encrypt and >decrypt any text-message or -file you want. >Our aim is, to give anyone the possibility to send and receive secure >encrypted messages anywhere - on any computer out there, no matter if >Microsoft Windows(TM) or Linux is running on it. Therefore it's usage is >self-describing, and the user-interface as simple as possible. >gpg4usb is free software, and it is licensed under the GNU General Public >License (GPL). From rjh at sixdemonbag.org Thu Nov 13 23:23:39 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 13 Nov 2014 17:23:39 -0500 Subject: gpg4usb: Portable GUI for GnuPG In-Reply-To: <54648C0D.6000307@roembden.net> References: <54648C0D.6000307@roembden.net> Message-ID: <54652F6B.2020905@sixdemonbag.org> >> gpg4usb is a very easy to use and small portable editor to encrypt and >> decrypt any text-message or -file you want. I mean no offense, but this seems like a really bad idea. Putting it on CD-ROM might be a pretty cool idea, but USB is just ... scary. According to Vint Cerf, roughly one in five desktop PCs is already pwned by malware. Plug your USB token into three different computers and you've got 50/50 odds of your crypto hardware being plugged into a machine that's under the control of a malicious adversary who wants to use your USB token as an infection vector. >> Our aim is, to give anyone the possibility to send and receive secure >> encrypted messages anywhere - on any computer out there, no matter if >> Microsoft Windows(TM) or Linux is running on it. Therefore it's usage is >> self-describing, and the user-interface as simple as possible. It's a great goal, but the way you're going about it makes me shiver. From david at gbenet.com Thu Nov 13 23:33:31 2014 From: david at gbenet.com (david at gbenet.com) Date: Thu, 13 Nov 2014 22:33:31 +0000 Subject: Help needed Message-ID: <546531BB.2000206@gbenet.com> Hi All, Background: I exported my keys to a USB stick. Then I copied my .gnupg to a new Linux laptop. Then I imported my keys. I thought that I would be fine. But I get the following error when signing my mail: "Key 0xAAd8C47D not found or not valid. The (sub-)key might have expired." The key is visible in Enigmail Kgpg Kleopatra GPA I'm not able to edit my key I can't enter my passphrase. Any help to resolve this issue gratefully appreciated. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xAAD8C47D.asc Type: application/pgp-keys Size: 4295 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Thu Nov 13 23:42:01 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 13 Nov 2014 23:42:01 +0100 Subject: Help needed In-Reply-To: <546531BB.2000206@gbenet.com> References: <546531BB.2000206@gbenet.com> Message-ID: <3308112.4yWUpR4njK@inno> Am Do 13.11.2014, 22:33:31 schrieb david at gbenet.com: > I exported my keys to a USB stick. Then I copied my .gnupg to a new > Linux laptop. Then I imported my keys. I thought that I would be > fine. It is unclear to me what exactly you are talking about. The terms "export" and "import" usually refer to the commands gpg --export[...] gpg --import But it also sounds like you have copied the whole directory ~/.gnupg/ If you have copied the directory then maybe the file permissions have not been preserved. Check whether secring.gpg has 600. And delete the file random_seed. If you have exported and imported instead then you are missing the trust database. You should either copy trustdb.gpg or export and import this data, too: gpg --export-ownertrust gpg --import-ownertrust Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From dougb at dougbarton.email Thu Nov 13 23:42:25 2014 From: dougb at dougbarton.email (Doug Barton) Date: Thu, 13 Nov 2014 14:42:25 -0800 Subject: Help needed In-Reply-To: <546531BB.2000206@gbenet.com> References: <546531BB.2000206@gbenet.com> Message-ID: <546533D1.7030106@dougbarton.email> On 11/13/14 2:33 PM, david at gbenet.com wrote: > Hi All, > > Background: > > I exported my keys to a USB stick. Then I copied my .gnupg to a new > Linux laptop. Then I imported my keys. I thought that I would be > fine. Why did you perform the second step? Just copy ~/.gnupg to the new system, delete random_seed, and you're done. Doug From rjh at sixdemonbag.org Fri Nov 14 01:41:39 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 13 Nov 2014 19:41:39 -0500 Subject: GnuPG 2.1 and Mailpile (LWN comments) about GPGME In-Reply-To: <87lhnfuij4.fsf@vigenere.g10code.de> References: <201411111521.21557.bernhard@intevation.de> <201411131008.51030.bernhard@intevation.de> <87ioij2wvy.fsf@vigenere.g10code.de> <5464C823.5090304@sixdemonbag.org> <87lhnfuij4.fsf@vigenere.g10code.de> Message-ID: <54654FC3.60301@sixdemonbag.org> On 11/13/2014 12:17 PM, Werner Koch wrote: > Did you want to test a beta installer? Sure, I'm up for that. > Any volunteer to maintain one? Can't. I'm a forensics researcher who's received some USG funding; in the eyes of a lot of people, especially post-Dual_EC_DRBG, I'd be suspect. It's best for the overall trustworthiness of GnuPG if I stay away from development tasks. I wish it was otherwise, but ... there you have it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From david at gbenet.com Fri Nov 14 01:12:24 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 00:12:24 +0000 Subject: Help needed In-Reply-To: <3308112.4yWUpR4njK@inno> References: <546531BB.2000206@gbenet.com> <3308112.4yWUpR4njK@inno> Message-ID: <546548E8.5040206@gbenet.com> On 13/11/14 22:42, Hauke Laging wrote: > Am Do 13.11.2014, 22:33:31 schrieb david at gbenet.com: > >> I exported my keys to a USB stick. Then I copied my .gnupg to a new >> Linux laptop. Then I imported my keys. I thought that I would be >> fine. > > It is unclear to me what exactly you are talking about. > > The terms "export" and "import" usually refer to the commands > gpg --export[...] > gpg --import > > But it also sounds like you have copied the whole directory ~/.gnupg/ > > > If you have copied the directory then maybe the file permissions have > not been preserved. Check whether secring.gpg has 600. And delete the > file random_seed. > > If you have exported and imported instead then you are missing the trust > database. You should either copy trustdb.gpg or export and import this > data, too: > > gpg --export-ownertrust > gpg --import-ownertrust > > > Hauke > Hauke I have my trustdb.gpg And I still get the same error message. Perhaps the correct question to ask is: "How do I transfer ALL files in my .gnupg onto another Linux laptop so that ALL functions work as before - i.e it works the same on both machines. I hope that is within the bounds of your understanding. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xAAD8C47D.asc Type: application/pgp-keys Size: 4295 bytes Desc: not available URL: From david at gbenet.com Fri Nov 14 00:59:25 2014 From: david at gbenet.com (david at gbenet.com) Date: Thu, 13 Nov 2014 23:59:25 +0000 Subject: Help needed In-Reply-To: <546533D1.7030106@dougbarton.email> References: <546531BB.2000206@gbenet.com> <546533D1.7030106@dougbarton.email> Message-ID: <546545DD.6000404@gbenet.com> On 13/11/14 22:42, Doug Barton wrote: > On 11/13/14 2:33 PM, david at gbenet.com wrote: >> Hi All, >> >> Background: >> >> I exported my keys to a USB stick. Then I copied my .gnupg to a new >> Linux laptop. Then I imported my keys. I thought that I would be >> fine. > > Why did you perform the second step? Just copy ~/.gnupg to the new system, delete > random_seed, and you're done. > > Doug > Doug, I just did that - and I get the same error message. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xAAD8C47D.asc Type: application/pgp-keys Size: 4295 bytes Desc: not available URL: From dougb at dougbarton.email Fri Nov 14 01:55:03 2014 From: dougb at dougbarton.email (Doug Barton) Date: Thu, 13 Nov 2014 16:55:03 -0800 Subject: Help needed In-Reply-To: <546545DD.6000404@gbenet.com> References: <546531BB.2000206@gbenet.com> <546533D1.7030106@dougbarton.email> <546545DD.6000404@gbenet.com> Message-ID: <546552E7.5090406@dougbarton.email> On 11/13/14 3:59 PM, david at gbenet.com wrote: > On 13/11/14 22:42, Doug Barton wrote: >> On 11/13/14 2:33 PM, david at gbenet.com wrote: >>> Hi All, >>> >>> Background: >>> >>> I exported my keys to a USB stick. Then I copied my .gnupg to a new >>> Linux laptop. Then I imported my keys. I thought that I would be >>> fine. >> >> Why did you perform the second step? Just copy ~/.gnupg to the new system, delete >> random_seed, and you're done. >> >> Doug >> > > Doug, > > I just did that - and I get the same error message. Did you fix the permissions on the ~/.gnupg directory to be 0700? What happens when you do 'gpg --list-keys' at the command line? BTW, please stop attaching your key to your posts. :) Doug From david at gbenet.com Fri Nov 14 02:39:31 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 01:39:31 +0000 Subject: Help needed In-Reply-To: <546552E7.5090406@dougbarton.email> References: <546531BB.2000206@gbenet.com> <546533D1.7030106@dougbarton.email> <546545DD.6000404@gbenet.com> <546552E7.5090406@dougbarton.email> Message-ID: <54655D53.9090908@gbenet.com> On 14/11/14 00:55, Doug Barton wrote: > On 11/13/14 3:59 PM, david at gbenet.com wrote: >> On 13/11/14 22:42, Doug Barton wrote: >>> On 11/13/14 2:33 PM, david at gbenet.com wrote: >>>> Hi All, >>>> >>>> Background: >>>> >>>> I exported my keys to a USB stick. Then I copied my .gnupg to a new >>>> Linux laptop. Then I imported my keys. I thought that I would be >>>> fine. >>> >>> Why did you perform the second step? Just copy ~/.gnupg to the new system, delete >>> random_seed, and you're done. >>> >>> Doug >>> >> >> Doug, >> >> I just did that - and I get the same error message. > > Did you fix the permissions on the ~/.gnupg directory to be 0700? What happens when you do > 'gpg --list-keys' at the command line? > > BTW, please stop attaching your key to your posts. :) > > Doug > > > Doug, Permissions: View content: Only owner Change content: Only owner Access control: Only owner When I do gpg --list-keys: pub 4096R/AAD8C47D 2014-08-17 uid postmaster (There's always light at the end of the tunnel) sub 4096R/FDDA1EF2 2014-08-17 gpg list all keys 198 of them David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From rjh at sixdemonbag.org Fri Nov 14 03:15:17 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 13 Nov 2014 21:15:17 -0500 Subject: Fermi estimates Message-ID: <546565B5.3040107@sixdemonbag.org> A while ago Hauke asked if the statement in the FAQ about a brute-forcer leaving the Earth uninhabitable was correct. I said it was, but I didn't break out the math. Now that I have a few minutes to breathe, here's the full answer. It's a Fermi estimate, which means it's not going to be perfectly accurate. It's going to be in the ballpark, but more than that isn't guaranteed. The Landauer bound: you can't flip a bit using less than 10**-29 joules of energy. The Margolus-Levitin theorem: at 10**-29 joules of energy, you can't make it flip faster than 10**-5 seconds. Let's estimate the bitflips needed to check a key at a cool one million. That covers loading the new key, populating key schedules, doing a trial decryption, the whole nine yards. 10**6 operations per key. Let's also say your computer can flip 100 bits at a time (10**2). 10**6 bits per key, processed 10**2 at a time, means a total elapsed time of (10**6 / 10 **2 = 10**4 bitflips per thread, multiplied by 10**-5 seconds per bitflip, equals 10**-1 seconds) a tenth of a second per key. Now, before you say "but my computer's much faster than that!", your computer also isn't running on less power than you generate by scuffing your feet on the carpet. We'll be exploring faster computers in a bit. Breaking a 128-bit cipher by brute force requires about 10**38 key attempts. 10**38 attempts times 10**-1 seconds per attempt equals ... uh ... a lot of seconds. 10**37. A year is more or less 10**7 seconds, so 10**30 years. The universe is about 10 billion years old, or 10**13 years, so ... our brute-force key cracker takes 10**17 times longer than the age of the universe in order to brute-force a 128-bit key. Clearly, we need to speed things up a bit. We need to upgrade from a carpet-scuffing system to two hamsters running on a treadmill. Unfortunately, that's only a few thousandfold power improvement, so we're going to have to give the hamsters amphetamines to get them the rest of the way. Now, with 10**30 times the power input (these are some *good* amphetamines), our brute-forcer will be finished in a single year. 10**38 attempts at 10**6 bitflips per attempt equals 10**44 bitflips total. At carpet-scuffing power, that's about 10**15 joules of energy, or about a single one-megaton nuclear bomb. Admittedly, that energy gets released over 10**13 times the age of the universe, so that's not a big problem. But to make our brute-forcer 10**30 times faster (so it can run in one year), our brute-forcer also has to release 10**30 times as much heat. I'm not an astrophysicist, but that's the kind of energy levels one normally associates with phrases like "perturb the false vacuum" and "unmake the universe at the speed of light." Look at the time, I must be going. Also: I'm hiring for a minion. (Lackey, lickspittle, graduate student. Call it what you like.) The pay is almost nothing, but somebody's got to clean the hamster cage while I'm gone. I'm moving to the nearest convenient parallel dimension. It's getting weird and dangerous around here... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Fri Nov 14 03:36:34 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 13 Nov 2014 21:36:34 -0500 Subject: Fermi estimates In-Reply-To: <546565B5.3040107@sixdemonbag.org> References: <546565B5.3040107@sixdemonbag.org> Message-ID: <54656AB2.2070802@sixdemonbag.org> Whoops! > so 10**30 years. The universe is about 10 billion years old, or > 10**13 years, so ... our brute-force key cracker takes 10**17 times > longer than the age of the universe in order to brute-force a 128-bit > key. 10 billion is 10**10, so it takes 10**20 times the age of the universe. But at some point, who's counting? > Admittedly, that energy gets released over 10**13 times the age of > the universe... 10**20. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From david at gbenet.com Fri Nov 14 03:31:30 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 02:31:30 +0000 Subject: Help needed In-Reply-To: <546552E7.5090406@dougbarton.email> References: <546531BB.2000206@gbenet.com> <546533D1.7030106@dougbarton.email> <546545DD.6000404@gbenet.com> <546552E7.5090406@dougbarton.email> Message-ID: <54656982.40305@gbenet.com> On 14/11/14 00:55, Doug Barton wrote: > On 11/13/14 3:59 PM, david at gbenet.com wrote: >> On 13/11/14 22:42, Doug Barton wrote: >>> On 11/13/14 2:33 PM, david at gbenet.com wrote: >>>> Hi All, >>>> >>>> Background: >>>> >>>> I exported my keys to a USB stick. Then I copied my .gnupg to a new >>>> Linux laptop. Then I imported my keys. I thought that I would be >>>> fine. >>> >>> Why did you perform the second step? Just copy ~/.gnupg to the new system, delete >>> random_seed, and you're done. >>> >>> Doug >>> >> >> Doug, >> >> I just did that - and I get the same error message. > > Did you fix the permissions on the ~/.gnupg directory to be 0700? What happens when you do > 'gpg --list-keys' at the command line? > > BTW, please stop attaching your key to your posts. :) > > Doug > > > Doug, Even when I use a backup programme and restore I still get the same error message. So no-one has ever copied their .gnupg folder to another laptop. No one has ever done this with any success. You have all failed. Clearly there's something wrong with gnupg that does not like being backed up copied whatever. If it were another programme say Thunderbird no one would use Thunderbird. They would say Thunderbird was crap. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From dkg at fifthhorseman.net Fri Nov 14 05:11:02 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Nov 2014 18:11:02 -1000 Subject: Help needed In-Reply-To: <54656982.40305@gbenet.com> References: <546531BB.2000206@gbenet.com> <546533D1.7030106@dougbarton.email> <546545DD.6000404@gbenet.com> <546552E7.5090406@dougbarton.email> <54656982.40305@gbenet.com> Message-ID: <546580D6.2020403@fifthhorseman.net> Hi David-- You sound frustrated. hopefully we can help you figure things out. Some of the details of what's happened on your machine(s) sound unclear to me, and we'll be able to help you better with more precise information. On 11/13/2014 04:31 PM, david at gbenet.com wrote: > Even when I use a backup programme and restore I still get the same error message. What backup program did you use? What version of gnupg were you using on your old computer? what platform was your old machine? what platform is your new machine? If you feel comfortable sharing any of this information, i'd be curious to see the outcome (on both old and new machines) of any of the following series of commands: uname -a ls -la ~/.gnupg gpg --version gpg --list-secret-keys 0xAAD8C47D echo test | gpg --clearsign -u 0xAAD8C47D If it looks like this information is too sensitive to post to the list, but you feel ok sending it to me privately, you're welcome to send it to me privately (my OpenPGP fingerprint is at the bottom of this mail if you wish to encrypt it). > So no-one > has ever copied their .gnupg folder to another laptop. No one has ever done this with any > success. I can say based on personal experience that this is not the case. I have done several such transfers, for myself and for other people. > You have all failed. Clearly there's something wrong with gnupg that does not like > being backed up copied whatever. If it were another programme say Thunderbird no one would > use Thunderbird. They would say Thunderbird was crap. I'm going to treat this paragraph as you expressing your frustration, instead of reading it as an attack on the developers of GnuPG. Other people might read it differently, and may find it demotivating in terms of helping you with your current situation. Please remember that there are human beings on the other side of your e-mail, people who are remarkably committed to helping others, but who also have their own feelings. Regards, --dkg OpenPGP Fingerprint: 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From Mustrum at Mustrum.net Thu Nov 13 21:00:38 2014 From: Mustrum at Mustrum.net (Mustrum) Date: Thu, 13 Nov 2014 21:00:38 +0100 Subject: GnuPG 2.1.0 Merging secret key Message-ID: <54650DE6.3010800@Mustrum.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, >My guess would be the option "--try-secret-key name" where "name" might be the subkey's new ID followed by an exclamation mark. Nope I got the error "no secret key available". I'm wondering : what is the planned usage for that feature ? -----BEGIN PGP SIGNATURE----- iJ4EARMKAAYFAlRlDdgACgkQduVShR3cXu8gzgH+M0ZxuU6D8NfotRxW+D0PFdP3 zn34TNeuRiRfgYTL0bScZ1YrvYaJM0nW8ULWMnoK/i8NvXLBJ2s9xrEhyfyFZQIA p8LbtduQ9eO/x24LHNs5hYeP2uRP8zqdIkr/MYxO2Ux2MjLXi2joeV2UZWygTLpl h3ejCQwBC8RQ1Ht9Pi8vRA== =VolJ -----END PGP SIGNATURE----- From wk at gnupg.org Fri Nov 14 08:58:45 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Nov 2014 08:58:45 +0100 Subject: GnuPG 2.1.0 Merging secret key In-Reply-To: <54650DE6.3010800@Mustrum.net> (Mustrum@mustrum.net's message of "Thu, 13 Nov 2014 21:00:38 +0100") References: <54650DE6.3010800@Mustrum.net> Message-ID: <87389musay.fsf@vigenere.g10code.de> On Thu, 13 Nov 2014 21:00, Mustrum at Mustrum.net said: > I'm wondering : what is the planned usage for that feature ? --try-secret-keys is used to specify keys to be used in addition to the default secret key when it comes to decrypt messages with anonymous recipients. I have often the case that I receive a messages encrypted to a bunch of keys where many of them use an anonymous recipient (e.g. for private backup keys). By using this option I can define which of my secret keys are to be used for trial decryption. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From johanw at vulcan.xs4all.nl Fri Nov 14 10:25:51 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 14 Nov 2014 10:25:51 +0100 Subject: Fermi estimates In-Reply-To: <546565B5.3040107@sixdemonbag.org> References: <546565B5.3040107@sixdemonbag.org> Message-ID: <5465CA9F.20706@vulcan.xs4all.nl> On 14-11-2014 3:15, Robert J. Hansen wrote: > 10**38 attempts at 10**6 bitflips per attempt equals 10**44 bitflips > total. At carpet-scuffing power, that's about 10**15 joules of energy, [...] > But to make our brute-forcer 10**30 times faster (so it > can run in one year), our brute-forcer also has to release 10**30 times > as much heat. > > I'm not an astrophysicist, but that's the kind of energy levels one > normally associates with phrases like "perturb the false vacuum" and > "unmake the universe at the speed of light." Look at the time, I must > be going. Fortunately there's no false vacuum left to perturb. :-) Anyway, compared to the Sun's output of 3.82*10**26W that's still quite large. > 10 billion is 10**10, PLEASE don't do that in a FAQ. The definitions of bilion, biljard etc. differ wether one uses imperial or SI units, and thuis makes it very confusing. For me, a bilion is 10**12. It wouldn't be the first estimate that was off by some factors 10**6 due to mixing these up. Better to avoid those terms completely. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From david at gbenet.com Fri Nov 14 10:45:14 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 09:45:14 +0000 Subject: Help needed In-Reply-To: <546580D6.2020403@fifthhorseman.net> References: <546531BB.2000206@gbenet.com> <546533D1.7030106@dougbarton.email> <546545DD.6000404@gbenet.com> <546552E7.5090406@dougbarton.email> <54656982.40305@gbenet.com> <546580D6.2020403@fifthhorseman.net> Message-ID: <5465CF2A.1040107@gbenet.com> On 14/11/14 04:11, Daniel Kahn Gillmor wrote: > Hi David-- > > You sound frustrated. hopefully we can help you figure things out. > > Some of the details of what's happened on your machine(s) sound unclear > to me, and we'll be able to help you better with more precise information. > > On 11/13/2014 04:31 PM, david at gbenet.com wrote: >> Even when I use a backup programme and restore I still get the same error message. > > What backup program did you use? What version of gnupg were you using > on your old computer? what platform was your old machine? what > platform is your new machine? > > If you feel comfortable sharing any of this information, i'd be curious > to see the outcome (on both old and new machines) of any of the > following series of commands: > > uname -a > ls -la ~/.gnupg > gpg --version > gpg --list-secret-keys 0xAAD8C47D > echo test | gpg --clearsign -u 0xAAD8C47D > > If it looks like this information is too sensitive to post to the list, > but you feel ok sending it to me privately, you're welcome to send it to > me privately (my OpenPGP fingerprint is at the bottom of this mail if > you wish to encrypt it). > >> So no-one >> has ever copied their .gnupg folder to another laptop. No one has ever done this with any >> success. > > I can say based on personal experience that this is not the case. I > have done several such transfers, for myself and for other people. > >> You have all failed. Clearly there's something wrong with gnupg that does not like >> being backed up copied whatever. If it were another programme say Thunderbird no one would >> use Thunderbird. They would say Thunderbird was crap. > > I'm going to treat this paragraph as you expressing your frustration, > instead of reading it as an attack on the developers of GnuPG. Other > people might read it differently, and may find it demotivating in terms > of helping you with your current situation. > > Please remember that there are human beings on the other side of your > e-mail, people who are remarkably committed to helping others, but who > also have their own feelings. > > Regards, > > --dkg > > OpenPGP Fingerprint: 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 > > Hi Daniel, Firstly I can neither encrypt or sign. I have two laptops (1) 32 bit LXD (2) 64 bit LXD my 64 bit machine crashed and went off for repairs. It came back I reinstalled the operating system and all programmes - now a mirror image of my 32 bit LXD. Then I did the following: (1) david at laptop-1:~$ gpg gpg: directory `/home/david/.gnupg' created gpg: new configuration file `/home/david/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/david/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/home/david/.gnupg/secring.gpg' created gpg: keyring `/home/david/.gnupg/pubring.gpg' created gpg: Go ahead and type your message ... (2) Run ALL your GUIs eg Kgpg Kleopatra GPA - but do not create a new set of keys! Kgpg will complain and not run. (3) Reboot your system - very important! (4) Type david at laptop-1:~$ gpg-agent gpg-agent: gpg-agent running and available david at laptop-1:~$ Then I copied ALL .gnupg files from the 32 bit laptop to the 64 bit laptop - on the 32 bit laptop I exported my keys saving them to a file - I did this twice. Then I imported my keys into the 64 bit laptop. All programmes see my key - even gpg but I always get the same error message: "Key 0xAAd8C47D not found or not valid. The (sub-)key might have expired" when I try to sign or encrypt a message. Now insted of copying ALL the files from one .gnupg to another am just going to copy secring.gpg and trustdb.gpg - then import my keys - if this works then you will know how to do it in the future - if it does not work - hmmmmmmm............... David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From johanw at vulcan.xs4all.nl Fri Nov 14 10:55:59 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 14 Nov 2014 10:55:59 +0100 Subject: gpg4usb: Portable GUI for GnuPG In-Reply-To: <54652F6B.2020905@sixdemonbag.org> References: <54648C0D.6000307@roembden.net> <54652F6B.2020905@sixdemonbag.org> Message-ID: <5465D1AF.5010601@vulcan.xs4all.nl> On 13-11-2014 23:23, Robert J. Hansen wrote: > I mean no offense, but this seems like a really bad idea. Putting it on > CD-ROM might be a pretty cool idea, but USB is just ... scary. There exist USB sticks with a write-protection jumper (I have 2 so I'm sure). If those cannot be found, use a SD memory card (they all have such a jumper) in a SD to USB conversion unit. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From pete at heypete.com Fri Nov 14 10:36:22 2014 From: pete at heypete.com (Pete Stephenson) Date: Fri, 14 Nov 2014 10:36:22 +0100 Subject: Fermi estimates In-Reply-To: <5465CA9F.20706@vulcan.xs4all.nl> References: <546565B5.3040107@sixdemonbag.org> <5465CA9F.20706@vulcan.xs4all.nl> Message-ID: On Fri, Nov 14, 2014 at 10:25 AM, Johan Wevers wrote: > On 14-11-2014 3:15, Robert J. Hansen wrote: > >> 10**38 attempts at 10**6 bitflips per attempt equals 10**44 bitflips >> total. At carpet-scuffing power, that's about 10**15 joules of energy, > [...] >> But to make our brute-forcer 10**30 times faster (so it >> can run in one year), our brute-forcer also has to release 10**30 times >> as much heat. >> >> I'm not an astrophysicist, but that's the kind of energy levels one >> normally associates with phrases like "perturb the false vacuum" and >> "unmake the universe at the speed of light." Look at the time, I must >> be going. > > Fortunately there's no false vacuum left to perturb. :-) > > Anyway, compared to the Sun's output of 3.82*10**26W that's still quite > large. > >> 10 billion is 10**10, > > PLEASE don't do that in a FAQ. The definitions of bilion, biljard etc. > differ wether one uses imperial or SI units, and thuis makes it very > confusing. For me, a bilion is 10**12. It wouldn't be the first estimate > that was off by some factors 10**6 due to mixing these up. Better to > avoid those terms completely. Minor nitpick: the difference between the "long" and "short" scales are a bit more involved than just "imperial" vs. "SI". More details are at https://en.wikipedia.org/wiki/Long_and_short_scales But yes, avoiding ambiguous words like "billion" is a good idea. Using notation like 10^9, 10^12, etc. would make things more clear to readers regardless of what words they use to describe those numbers. Cheers! -Pete -- Pete Stephenson From david at gbenet.com Fri Nov 14 11:42:33 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 10:42:33 +0000 Subject: My Conclusions Message-ID: <5465DC99.3060803@gbenet.com> Hi All, After spending 62 hours on what I thought would be a simple task namely to get a fully functioning gnupg mirror on my 64 bit Linux system - I realise this is an impossible task to do. In the past I've ended up creating a new set of certificates - but this time round I thought that I would apply some effort. My conclusion is It IS Impossible To Transfer Your Keys From The Same O/S To Another Machine. There is no one in the entire universe that has ever attempted it. And if they have THEY HAVE FAILED. Not one person on this list knows how to do it successfully. No one. NOT ONE OF YOU can transfer a mirror image of your .gnupg folder and expect it to work. This tells me what I have long suspected - yes it's good at encryption and signing but the programme is fundamentally flawed as to make it utter crap. My keys are PERFECT but the software is CRAP. Werner Koch knows it's crap. Every one knows it's crap. So, If I want to go on signing and encrypting my emails I HAVE TO CREATE ANOTHER SET A BLOODY KEYS!!!!!!!! I am not a happy bunny!!! David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From flapflap at riseup.net Fri Nov 14 12:16:16 2014 From: flapflap at riseup.net (flapflap) Date: Fri, 14 Nov 2014 11:16:16 +0000 Subject: gpg4usb: Portable GUI for GnuPG In-Reply-To: <5465D1AF.5010601@vulcan.xs4all.nl> References: <54648C0D.6000307@roembden.net> <54652F6B.2020905@sixdemonbag.org> <5465D1AF.5010601@vulcan.xs4all.nl> Message-ID: <5465E480.4060103@riseup.net> Johan Wevers wrote: > On 13-11-2014 23:23, Robert J. Hansen wrote: > >> I mean no offense, but this seems like a really bad idea. Putting it on >> CD-ROM might be a pretty cool idea, but USB is just ... scary. > > There exist USB sticks with a write-protection jumper (I have 2 so I'm > sure). If those cannot be found, use a SD memory card (they all have > such a jumper) in a SD to USB conversion unit. if you refer to the "Lock" switch of SD memory cards, then please note that this "Lock" switch is only evaluated in OS software and no physical/electrical protection of the flash IC. Normally, the mechanic "Lock" switch only pushes away a contact on the SD card socket, so the OS can evaluate whether the contacts are conncted or not. On GNU/Linux I think it is sufficient to just mount -o remount,rw a previously read-only mounted SD card. USB sticks with real physical (i.e. electrically routed to the write-protect pin of the flash IC) write protection are rare, but they exist (as you said). From mustrum at mustrum.net Fri Nov 14 11:05:40 2014 From: mustrum at mustrum.net (Mustrum) Date: Fri, 14 Nov 2014 11:05:40 +0100 Subject: GnuPG 2.1.0 Merging secret key In-Reply-To: <87389musay.fsf@vigenere.g10code.de> References: <54650DE6.3010800@Mustrum.net> <87389musay.fsf@vigenere.g10code.de> Message-ID: <8A3E83AC-B6FB-4838-9DB3-6E876A34D69C@mustrum.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I was wondering about merging secret keys. Le 14 novembre 2014 08:58:45 CET, Werner Koch a ?crit : >On Thu, 13 Nov 2014 21:00, Mustrum at Mustrum.net said: > >> I'm wondering : what is the planned usage for that feature ? > >--try-secret-keys is used to specify keys to be used in addition to the >default secret key when it comes to decrypt messages with anonymous >recipients. > >I have often the case that I receive a messages encrypted to a bunch of >keys where many of them use an anonymous recipient (e.g. for private >backup keys). By using this option I can define which of my secret >keys >are to be used for trial decryption. > > >Shalom-Salam, > > Werner > >-- >Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI7BAEBCgAlBQJUZdP0HhxNdXN0cnVtIDxNdXN0cnVtQE11c3RydW0ubmV0PgAK CRDXUCfO5tif7hIED/wJnKHLep7kSWxlDuM6gJn+SA9yvszpeCQmsxpy2FE7co0s 7+ZUy1IkdQBWarkJ5Q3K2Ytxn72p2DbOSX471iSGivoJwsQiQxUwgpzYOqAjL9vd EaiybtoW2WcAU/a6a+7VQ+voV9HwugL0i8cG5XiMB92DYL7s0nzeupHUdVAIsVF8 1/LzphzqfX6lkpfdsnD5678W3yXS1rfqMu01s0gD1iMkBaFbZNzZZ8mThv7rg9FG iJqhvqhmP0gLfdWEWDSoEgPLP5uln1g9EO08fNZepzVomkdTsCXgoFl7Y4ndkwSi QnrhmhoPTIGPyb8KtIHK/lJWvhnePVZUjoVM83lOwlquj95iEu3ONxfkSobwadsV IgElqqdJqJ2kGILI9t0AFcjwG0c2o5sQixOMFMYrAAkDtP0S1h2LQBD1DxYCldhX gU0iaqg0F1IBGrXLzDjQECLNP+7fQSioKqDVwOpW6A3dt3OR12T0Thge9HQB/hH2 xX26SrMdC67brtp9BICMFKQRq9sy3XlsgLYcNOg9GSzaJ6oE5/vslHUWzF+3fBX0 eAj1BXFRBM2r6mFGANkvCF5VQgJJJFpKjyld0l6LoPOc+eOjMsa0Z/8Mixurxu4E 7VNQhqV3MPPR0xO4311qgd8YHvVfs2zFr1QXTgMXwi1brq5HBuZpQvs5Vwu0jQ== =2uLE -----END PGP SIGNATURE----- From nicholas.cole at gmail.com Fri Nov 14 12:34:27 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 14 Nov 2014 11:34:27 +0000 Subject: My Conclusions In-Reply-To: <5465DC99.3060803@gbenet.com> References: <5465DC99.3060803@gbenet.com> Message-ID: David, I'm sorry you are having problems, but I think this is just nonsense. Of course people move keys between machines all the time. I have done it myself often. I don't think that anyone deserves that level of abuse -- certainly not someone who has put years of work into a program that is an industry standard and released it for free. Nicholas On Fri, Nov 14, 2014 at 10:42 AM, david at gbenet.com wrote: > Hi All, > > After spending 62 hours on what I thought would be a simple task namely to get a fully > functioning gnupg mirror on my 64 bit Linux system - I realise this is an impossible task to > do. In the past I've ended up creating a new set of certificates - but this time round I > thought that I would apply some effort. > > My conclusion is It IS Impossible To Transfer Your Keys From The Same O/S To Another Machine. > > There is no one in the entire universe that has ever attempted it. And if they have THEY > HAVE FAILED. Not one person on this list knows how to do it successfully. No one. NOT ONE OF > YOU can transfer a mirror image of your .gnupg folder and expect it to work. > > This tells me what I have long suspected - yes it's good at encryption and signing but the > programme is fundamentally flawed as to make it utter crap. My keys are PERFECT but the > software is CRAP. Werner Koch knows it's crap. Every one knows it's crap. > > So, If I want to go on signing and encrypting my emails I HAVE TO CREATE ANOTHER SET A > BLOODY KEYS!!!!!!!! > > I am not a happy bunny!!! > > David > > > > > -- > ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No > delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From david at gbenet.com Fri Nov 14 12:41:46 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 11:41:46 +0000 Subject: Why the software is crap Message-ID: <5465EA7A.2050005@gbenet.com> Hello All, I even tried exporting my private and public key from the command line and then tried importing. The same error message as before. I have checked on the internet - most of the suggestions are crap - the authors have never ever tried to do what they suggest others to do. If they had done so then they would have known just how crappy their supposed expertise was. I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a useless pile of crap also. I am faced with two options: (1) Create yet another set of keys (2) Give up using gnupg after some 20 years I think I will unsubscribe from this list and give up on gnupg as a pile of crap. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 12:45:48 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 11:45:48 +0000 Subject: My Conclusions In-Reply-To: References: <5465DC99.3060803@gbenet.com> Message-ID: <5465EB6C.8070302@gbenet.com> On 14/11/14 11:34, Nicholas Cole wrote: > David, > > I'm sorry you are having problems, but I think this is just nonsense. > Of course people move keys between machines all the time. I have done > it myself often. I don't think that anyone deserves that level of > abuse -- certainly not someone who has put years of work into a > program that is an industry standard and released it for free. > > Nicholas > > On Fri, Nov 14, 2014 at 10:42 AM, david at gbenet.com wrote: >> Hi All, >> >> After spending 62 hours on what I thought would be a simple task namely to get a fully >> functioning gnupg mirror on my 64 bit Linux system - I realise this is an impossible task to >> do. In the past I've ended up creating a new set of certificates - but this time round I >> thought that I would apply some effort. >> >> My conclusion is It IS Impossible To Transfer Your Keys From The Same O/S To Another Machine. >> >> There is no one in the entire universe that has ever attempted it. And if they have THEY >> HAVE FAILED. Not one person on this list knows how to do it successfully. No one. NOT ONE OF >> YOU can transfer a mirror image of your .gnupg folder and expect it to work. >> >> This tells me what I have long suspected - yes it's good at encryption and signing but the >> programme is fundamentally flawed as to make it utter crap. My keys are PERFECT but the >> software is CRAP. Werner Koch knows it's crap. Every one knows it's crap. >> >> So, If I want to go on signing and encrypting my emails I HAVE TO CREATE ANOTHER SET A >> BLOODY KEYS!!!!!!!! >> >> I am not a happy bunny!!! >> >> David >> >> >> >> >> -- >> ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the >> kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No >> delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I have done everything correctly - and my conclusions are still the same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION PROGRAMME THAT WORKS. THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU HAVE NEVER EVER DONE IT. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From martin-gnupg-users at dkyb.de Fri Nov 14 12:55:40 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Fri, 14 Nov 2014 12:55:40 +0100 Subject: Why the software is crap In-Reply-To: <5465EA7A.2050005@gbenet.com> References: <5465EA7A.2050005@gbenet.com> Message-ID: <5465EDBC.2000908@dkyb.de> Am 14.11.2014 um 12:41 schrieb david at gbenet.com: > Hello All, > > I even tried exporting my private and public key from the command line and then tried > importing. The same error message as before. I have checked on the internet - most of the > suggestions are crap - the authors have never ever tried to do what they suggest others to > do. If they had done so then they would have known just how crappy their supposed expertise was. > > I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a > useless pile of crap also. > > I am faced with two options: > > (1) Create yet another set of keys > (2) Give up using gnupg after some 20 years > > I think I will unsubscribe from this list and give up on gnupg as a pile of crap. > > David > I think unsubscribing is the best thing you can do. Because you probably successfully destroyed the good intension and motivation of anyone helping you, with the offending nonsense you wrote in your last mails. If you are angry just shut up and write again after you cooled yourself down. The problem is more likely with you because there are not many people reporting such problems. And I can tell from my own experience that it is not even a problem copying the content of the gnupg directory between windows and linux. Tried that successfully. Maybe you should read the FAQ again (and try to understand what is written). Maybe there is a difference between exporting the public part of a key and the private part. Anyway, enjoy your life. Martin From david at gbenet.com Fri Nov 14 13:24:26 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 12:24:26 +0000 Subject: Why the software is crap In-Reply-To: <5465EDBC.2000908@dkyb.de> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> Message-ID: <5465F47A.2000709@gbenet.com> On 14/11/14 11:55, Martin Behrendt wrote: > Am 14.11.2014 um 12:41 schrieb david at gbenet.com: >> Hello All, >> >> I even tried exporting my private and public key from the command line and then tried >> importing. The same error message as before. I have checked on the internet - most of the >> suggestions are crap - the authors have never ever tried to do what they suggest others to >> do. If they had done so then they would have known just how crappy their supposed expertise was. >> >> I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a >> useless pile of crap also. >> >> I am faced with two options: >> >> (1) Create yet another set of keys >> (2) Give up using gnupg after some 20 years >> >> I think I will unsubscribe from this list and give up on gnupg as a pile of crap. >> >> David >> > > I think unsubscribing is the best thing you can do. Because you probably > successfully destroyed the good intension and motivation of anyone > helping you, with the offending nonsense you wrote in your last mails. > > If you are angry just shut up and write again after you cooled yourself > down. The problem is more likely with you because there are not many > people reporting such problems. > And I can tell from my own experience that it is not even a problem > copying the content of the gnupg directory between windows and linux. > Tried that successfully. > Maybe you should read the FAQ again (and try to understand what is > written). Maybe there is a difference between exporting the public part > of a key and the private part. > > Anyway, enjoy your life. > Martin > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Martin, I have cooled. You can export your private key - you can export your public key. You can import your private key you can import your public key. In 20 years I have always had the same problem - the same error message and have each time created a new set of keys. I have done this 4 times. I notice that no one on this list - for all the talk of "oh I've done it" can offer no practical information has to HOW. No one. No one. No one knows how to do this simple task. In all my 20 years I have never found out how. Perhaps things are different under a Windows O/S but on Linux there is NO SOLUTION. Perhaps the only "solution" is to import ones private and public keys and lose all your contacts - ie a brand new installation. But I repeat BUT no one has ever created a mirror image of a .gnupg and had a fully 100 per cent working signing and encryption functionality. No one. There are no real practical solutions written anywhere on the internet. There is nothing of any value in https://www.gnupg.org/faq/GnuPG-FAQ.html - there never was in all the 20 years of reading it. Sure you can moan criticise me for my getting frustrated - and you can all moan and cringe and all withdraw your support - BUT NO ONE HAS EVER OFFERED ANY PRACTICAL USEFUL ADVICE THAT WILL ENABLE ME TO TRANSFER MY KEYS AND HAVE THEM WORKING CORRECTLY. NO ONE. NOT EVEN YOU. You are offended? Why? It is an easy thing to do is it not to moan about what and how people express themselves - yet you completely ignore the real issue. You ignore is because you can offer no real meaningful solution. As I have said no one has ever successfully transferred their public and private keys between machines and got them to successfully work. That's a real fact. And no one on this list as any practical solutions that work in the real world. That's a fact. The fact is no one on this list has ever done it with 100 per cent success. That's a fact. There is no practical advice on the internet. That's a fact. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From samir at samirnassar.com Fri Nov 14 13:37:57 2014 From: samir at samirnassar.com (Samir Nassar) Date: Fri, 14 Nov 2014 13:37:57 +0100 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <4120517.Z87MTM4IoF@forge> David, It might not be clear, but many of us have easily and simply migrated our .gnupg directories from computer to computer. I've even deleted my .gnupg directory and restored it from backups. I've intentionally messed up my private key and restored my private key to working status from backups. I guess I don't understand why you can't copy .gnupg from one system to another system. Yelling on the mailing list is extremely rude. It is now very clear, and archived, how you feel about the topic. Repeating yourself further in the manner you have been using will only alienate people and will not move you to a resolution. You've registered your complaint, it has been discussed, and now your behavior is counter-productive. Samir -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From ndk.clanbo at gmail.com Fri Nov 14 12:47:39 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 14 Nov 2014 12:47:39 +0100 Subject: Why the software is crap In-Reply-To: <5465EA7A.2050005@gbenet.com> References: <5465EA7A.2050005@gbenet.com> Message-ID: <5465EBDB.5060701@gmail.com> Il 14/11/2014 12:41, david at gbenet.com ha scritto: I usually just lurk, but that's too much... > I even tried exporting my private and public key from the command line and then tried > importing. The same error message as before. I have checked on the internet - most of the > suggestions are crap - the authors have never ever tried to do what they suggest others to > do. If they had done so then they would have known just how crappy their supposed expertise was. > I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a > useless pile of crap also. Surely you're doing it wrong, overlooking some passage. So don't blame others for something *you* are doing wrong. > I am faced with two options: > (1) Create yet another set of keys > (2) Give up using gnupg after some 20 years (3) Do it the right way as everyone else and admit you were doing something wrong. > I think I will unsubscribe from this list and give up on gnupg as a pile of crap. And that will be better for the whole community. BYtE, Diego. From tristan.santore at internexusconnect.net Fri Nov 14 13:41:12 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Fri, 14 Nov 2014 13:41:12 +0100 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <5465F868.7040303@internexusconnect.net> On 14/11/14 13:24, david at gbenet.com wrote: > On 14/11/14 11:55, Martin Behrendt wrote: >> Am 14.11.2014 um 12:41 schrieb david at gbenet.com: >>> Hello All, >>> >>> I even tried exporting my private and public key from the command line and then tried >>> importing. The same error message as before. I have checked on the internet - most of the >>> suggestions are crap - the authors have never ever tried to do what they suggest others to >>> do. If they had done so then they would have known just how crappy their supposed expertise was. >>> >>> I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a >>> useless pile of crap also. >>> >>> I am faced with two options: >>> >>> (1) Create yet another set of keys >>> (2) Give up using gnupg after some 20 years >>> >>> I think I will unsubscribe from this list and give up on gnupg as a pile of crap. >>> >>> David >>> >> >> I think unsubscribing is the best thing you can do. Because you probably >> successfully destroyed the good intension and motivation of anyone >> helping you, with the offending nonsense you wrote in your last mails. >> >> If you are angry just shut up and write again after you cooled yourself >> down. The problem is more likely with you because there are not many >> people reporting such problems. >> And I can tell from my own experience that it is not even a problem >> copying the content of the gnupg directory between windows and linux. >> Tried that successfully. >> Maybe you should read the FAQ again (and try to understand what is >> written). Maybe there is a difference between exporting the public part >> of a key and the private part. >> >> Anyway, enjoy your life. >> Martin >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > Martin, > > I have cooled. You can export your private key - you can export your public key. You can > import your private key you can import your public key. In 20 years I have always had the > same problem - the same error message and have each time created a new set of keys. I have > done this 4 times. > > I notice that no one on this list - for all the talk of "oh I've done it" can offer no > practical information has to HOW. No one. No one. No one knows how to do this simple task. > In all my 20 years I have never found out how. Perhaps things are different under a Windows > O/S but on Linux there is NO SOLUTION. > > Perhaps the only "solution" is to import ones private and public keys and lose all your > contacts - ie a brand new installation. But I repeat BUT no one has ever created a mirror > image of a .gnupg and had a fully 100 per cent working signing and encryption functionality. > No one. There are no real practical solutions written anywhere on the internet. > > There is nothing of any value in https://www.gnupg.org/faq/GnuPG-FAQ.html - there never was > in all the 20 years of reading it. > > Sure you can moan criticise me for my getting frustrated - and you can all moan and cringe > and all withdraw your support - BUT NO ONE HAS EVER OFFERED ANY PRACTICAL USEFUL ADVICE THAT > WILL ENABLE ME TO TRANSFER MY KEYS AND HAVE THEM WORKING CORRECTLY. NO ONE. NOT EVEN YOU. > > You are offended? Why? It is an easy thing to do is it not to moan about what and how people > express themselves - yet you completely ignore the real issue. You ignore is because you can > offer no real meaningful solution. As I have said no one has ever successfully transferred > their public and private keys between machines and got them to successfully work. That's a > real fact. And no one on this list as any practical solutions that work in the real world. > That's a fact. The fact is no one on this list has ever done it with 100 per cent success. > That's a fact. There is no practical advice on the internet. That's a fact. > > David > > David, I am pretty sure I have seen advice on how to backup and restore your keys, if not on this list, in the countless smartcard how to. I must admit I have not followed previous threads from you, but you must admit and be fair, that generally most people here are friendly and supportive. But I have seen the topic come up a few times, so maybe this is a security versus usability issue ? But again, I have not followed exactly what your problem is. Just wanted to point out that most people are reasonably helpful and friendly. Labelling gnupg as crap is, not exactly a fair assessment I think, and falls within the lines of labelling selinux crap, because people do not understand it/are confused by what is going on. Anyway. I hope you work it out in the end and I am sure, somebody will be willing yo nudge you in the right direction. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org From wk at gnupg.org Fri Nov 14 13:46:02 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 14 Nov 2014 13:46:02 +0100 Subject: My Conclusions In-Reply-To: (Nicholas Cole's message of "Fri, 14 Nov 2014 11:34:27 +0000") References: <5465DC99.3060803@gbenet.com> Message-ID: <87tx22t0fp.fsf@vigenere.g10code.de> On Fri, 14 Nov 2014 12:34, nicholas.cole at gmail.com said: > I'm sorry you are having problems, but I think this is just nonsense. > Of course people move keys between machines all the time. I have done Right. And you may even copy it from one OS to an entirely different one. The files are fully platform independent. Yet another of these gnome-keyring-daemon problems? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicole.faerber at kernelconcepts.de Fri Nov 14 12:56:50 2014 From: nicole.faerber at kernelconcepts.de (Nicole Faerber) Date: Fri, 14 Nov 2014 12:56:50 +0100 Subject: My Conclusions In-Reply-To: <5465EB6C.8070302@gbenet.com> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> Message-ID: <5465EE02.9090402@kernelconcepts.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh please, I am using gnupg with the same keys on at least five machines with no issue. I simply copied the .gnupg directory, end of story. Cheers nicole Am 14.11.2014 um 12:45 schrieb david at gbenet.com: > On 14/11/14 11:34, Nicholas Cole wrote: >> David, >> >> I'm sorry you are having problems, but I think this is just >> nonsense. Of course people move keys between machines all the >> time. I have done it myself often. I don't think that anyone >> deserves that level of abuse -- certainly not someone who has put >> years of work into a program that is an industry standard and >> released it for free. >> >> Nicholas >> >> On Fri, Nov 14, 2014 at 10:42 AM, david at gbenet.com >> wrote: >>> Hi All, >>> >>> After spending 62 hours on what I thought would be a simple >>> task namely to get a fully functioning gnupg mirror on my 64 >>> bit Linux system - I realise this is an impossible task to do. >>> In the past I've ended up creating a new set of certificates - >>> but this time round I thought that I would apply some effort. >>> >>> My conclusion is It IS Impossible To Transfer Your Keys From >>> The Same O/S To Another Machine. >>> >>> There is no one in the entire universe that has ever attempted >>> it. And if they have THEY HAVE FAILED. Not one person on this >>> list knows how to do it successfully. No one. NOT ONE OF YOU >>> can transfer a mirror image of your .gnupg folder and expect it >>> to work. >>> >>> This tells me what I have long suspected - yes it's good at >>> encryption and signing but the programme is fundamentally >>> flawed as to make it utter crap. My keys are PERFECT but the >>> software is CRAP. Werner Koch knows it's crap. Every one knows >>> it's crap. >>> >>> So, If I want to go on signing and encrypting my emails I HAVE >>> TO CREATE ANOTHER SET A BLOODY KEYS!!!!!!!! >>> >>> I am not a happy bunny!!! >>> >>> David >>> >>> >>> >>> >>> -- ?See the sanity of the man! No gods, no angels, no demons, >>> no body. Nothing of the kind.Stern, sane,every brain-cell >>> perfect and complete even at the moment of death. No delusion.? >>> https://linuxcounter.net/user/512854.html - http://gbenet.com >>> >>> _______________________________________________ Gnupg-users >>> mailing list Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> >> _______________________________________________ Gnupg-users >> mailing list Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > I have done everything correctly - and my conclusions are still the > same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR > .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION > PROGRAMME THAT WORKS. > > THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU > HAVE NEVER EVER DONE IT. > > David > > Viele Gr??e nicole faerber - -- kernel concepts GmbH Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBAgAGBQJUZe37AAoJEEKL5ZUtJ7x40m0L/AloGvm6i8cD4vktRtVsE2/n n289qTf6WbCaDxOPi5Z3N53/3AMTVrsshTx1eWMkqWynp5eGBYL8qY+o+OKfKe+t +NjkX2v5qWHJqZobFRc8umYzobCA73lqVyAqQdmmOb47Dcogw/6iO36mVVTgqjTm WPQasquaa8oBY+U+Rnb+H+kzM0nNGt5ucYNfMyez2cJpyVHcHSJVGl9gkXyh9UzA GBc8UHg5XHR0WsMj0aetsEmeD8zJrM4zV5bCiwe5R5zthKfbM6yvS0qyJ+x1UEOJ 9JfiQh+TdUBnZMzBZrmDVOECso6/SsMvLaixmYKeGozzcRnzgvSGLQter0Ykoye5 63pr0b8yd8AeHdYUpJ1P8/Zk9BPlPqK812pMfhE95FnOStIkMH8tQDf5k/PAV9Xp tpOEsdiiXG6jytpqaTR88T2wDbBfG0pMEOHaQdNddO8KXPfK9H0rg8DDvLCqtAYx TeWAKId8DCH0mMiadIns72ItnXB/Zkhe2MTtjY5AvQ== =Ze+M -----END PGP SIGNATURE----- From alexanderino at gmail.com Fri Nov 14 13:15:21 2014 From: alexanderino at gmail.com (Jason Antony) Date: Fri, 14 Nov 2014 23:15:21 +1100 Subject: My Conclusions In-Reply-To: <5465EB6C.8070302@gbenet.com> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> Message-ID: <5465F259.2030106@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-14 22:45, david at gbenet.com wrote: > I have done everything correctly - and my conclusions are still > the same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR > .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION > PROGRAMME THAT WORKS. But many have succeeded in it. Add myself to the list of people who have successfully backed up and re-used my GPG data files for over ten years, across various operating systems. It would be best to re-visit the problem when you're in a clear, calm frame of mind. All the best, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUZfJWAAoJED1Q2DsLuMaGZZ0P/2qXxbq5qaClxBhCB4/A9cIg s5FXxz3iLsTn2VRP6RC3r1J3BfaLMhS6fvru92/4eCx2JvLbkLtbYm2AZWhCdlSf wKIDZTczk+Ej5XAuqnsTZROagmxTNOyNnTdO+O4856Y6xXm0jTxmPBbVNU+xzm94 GGh1x4Q+iCCdm9S7yaHL6NWVUsqnp1Agy315DSXYHW+pKSzI+kgMgueDTdDg0nOM t0jXITW0Nw/K2xUjfbfDlwB2mRMuMpjTvTFqX63FNnrMPc+hlaN6xDs2C4Fn4V3K LTorP7v7dVw/9AYFnrWJ4Y8cP9xOoeTPCF5XlLlmD6SfcZ56xF8ucC++O1UBoe+j fprC/PSOLiVhkYIxwsyIv48+P42z+SDOfEnm71ejILAXk0j2I5ApJGUikMxXiaqJ 5d+qtCkmC5PHVYhfZhImTDXe92085ckC0r1UQ6cWA3n7DWi4gYBpUYUMmmBbL5IX pOfRxywzH2ukOHYB83jJ3HOboPzhgkv3hyQ9YLEsQmCL34ZK8BR9ZYkIzkvN8xqc MI6bBAclELDUrNFJRRH3RXBrQqqpce3XtNwDwY4urIjmyYfwENLAYNU3ekxPlkHV 9TfIJItQyjHdObgb6GxxVGIchsASFNZim74f2v6n0RoLU63d+KgQLOFSrGvE8H6M 3N6S0Vef3lTEYSiN4Qqo =aqZV -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Fri Nov 14 14:11:39 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 14 Nov 2014 14:11:39 +0100 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <5465FF8B.4000508@gmail.com> Il 14/11/2014 13:24, david at gbenet.com ha scritto: > I have cooled. You can export your private key - you can export your public key. You can > import your private key you can import your public key. In 20 years I have always had the > same problem - the same error message and have each time created a new set of keys. I have > done this 4 times. If all four times you did the same wrong thing, then it's obvious that you got the same wrong result. Just to prove it's your error, I copied my .gnupg from one system (str957-142) to another (str957-004), with the most basic method I ould think of. I'm not an expert (probably I transferred more than what was needed!), but as you can see I succeeded at the first try! diego at str957-142:~$ gpg --list-secret-keys /home/diego/.gnupg/secring.gpg ------------------------------------------------ sec 2048R/F9B9D307 2014-11-14 uid Diego ssb 2048R/3A4AD1C0 2014-11-14 diego at str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed .gnupg diego at str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz ? necessaria una passphrase per sbloccare la chiave segreta dell'utente: "Diego " 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 diego at str957-142:~$ ls GnuPG-backup.tar.gz* GnuPG-backup.tar.gz GnuPG-backup.tar.gz.asc diego at str957-142:~$ scp GnuPG-backup.tar.gz diego at str957-004:/home/diego Then on the other PC: diego at str957-004:~$ tar xvfz GnuPG-backup.tar.gz .gnupg/ .gnupg/gpg-agent-info .gnupg/pubring.kbx .gnupg/gpg.conf .gnupg/private-keys-v1.d/ .gnupg/reader_0.status .gnupg/pubring.gpg~ .gnupg/secring.gpg .gnupg/scdaemon.conf .gnupg/gpa.conf .gnupg/trustdb.gpg .gnupg/pubring.gpg diego at str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz ? necessaria una passphrase per sbloccare la chiave segreta dell'utente: "Diego " 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 diego at str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID chiave F9B9D307 gpg: Firma valida da "Diego " > I notice that no one on this list - for all the talk of "oh I've done it" can offer no > practical information has to HOW. No one. No one. No one knows how to do this simple task. > In all my 20 years I have never found out how. Perhaps things are different under a Windows > O/S but on Linux there is NO SOLUTION. Done just now in Ubuntu. So there's an error on your side. BYtE, Diego. From johanw at vulcan.xs4all.nl Fri Nov 14 14:14:43 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 14 Nov 2014 14:14:43 +0100 Subject: My Conclusions In-Reply-To: <5465EB6C.8070302@gbenet.com> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> Message-ID: <54660043.806@vulcan.xs4all.nl> On 14-11-2014 12:45, david at gbenet.com wrote: > I have done everything correctly Apparently not. Or maybe the files are corrupted? Do they still work on the original computer? > - and my conclusions are still the same NO ONE HAS EVER > SUCCESSFULLY MADE A MIRROR COPY OF THEIR .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING > AND ENCRYPTION PROGRAMME THAT WORKS. I did. Switched even between Linux and Windows, no problems. In the latter case, I did make a few changes to gnupg.conf since Windows has a different directory structure but that's all. > THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU HAVE NEVER EVER DONE IT. Stop shouting, we're neither deaf nor blind. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From johanw at vulcan.xs4all.nl Fri Nov 14 14:19:02 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 14 Nov 2014 14:19:02 +0100 Subject: gpg4usb: Portable GUI for GnuPG In-Reply-To: <5465E480.4060103@riseup.net> References: <54648C0D.6000307@roembden.net> <54652F6B.2020905@sixdemonbag.org> <5465D1AF.5010601@vulcan.xs4all.nl> <5465E480.4060103@riseup.net> Message-ID: <54660146.5050306@vulcan.xs4all.nl> On 14-11-2014 12:16, flapflap wrote: > if you refer to the "Lock" switch of SD memory cards, then please note > that this "Lock" switch is only evaluated in OS software and no > physical/electrical protection of the flash IC. [...] > USB sticks with real physical (i.e. electrically routed to the > write-protect pin of the flash IC) write protection are rare, but they > exist (as you said). I didn't know that, and I'm not sure if the sticks I have do the former or the later. I should try to remount them rw on a Linux box and then try to write something to them to test it. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From kristian.fiskerstrand at sumptuouscapital.com Fri Nov 14 14:21:46 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Fri, 14 Nov 2014 14:21:46 +0100 Subject: GnuPG 2.1.0: --refresh-keys regression In-Reply-To: <87mw7w69ue.fsf@vigenere.g10code.de> References: <20141111234920.06bff9e0@gentp.lnet> <87mw7w69ue.fsf@vigenere.g10code.de> Message-ID: <546601EA.60505@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/12/2014 10:34 AM, Werner Koch wrote: > On Tue, 11 Nov 2014 23:49, aranea at aixah.de said: > >> One of the changes introduced with GnuPG 2.1 -- namely, using >> dirmngr for key retrieval -- has caused some problems for me. >> First of all, I'm > > Thanks for reporting. I am already aware of it asdkg already > reported that a few days ago. Thank you for fixing this issue, I just confirmed it working nicely again in gpg (GnuPG) 2.1.1-beta17. > >> dirmngr also seems to have problems with hkps certificate >> checking for keyserver addresses with round-robin DNS, but I need >> to examine this further before I can provide details. > Seems we have the SNI issue back[0,1,2]. Another thing that also strike me is the number of attempts in the log for verification of this server rather than continuing to another one (see dirmngr snippet below). $ dig sks.karotte.org +short 176.9.51.79 At this point it goes the roundtrip via PTR again as we discussed earlier: $ dig -x 176.9.51.79 +short alita.karotte.org. And tries to use this as host for keyserver... but this host is not defined for SKS services and as such we get (i) a connection failure (CA cert is used rather than sks-keyservers.net CA) (ii) if accepting (i) a 404 as no virtualhost is set up for this offering SKS Sorry if the debug info part is a bit messy, but it shows the various scenarios when testing with curl to show the differences here. References: [0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028458.html [1] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028460.html [2] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028465.html Debug info: using hkps.pool.sks-keyservers.net as SNI (works using pool CA): > ---------------snip---------------< $ curl -vv --cacert $HOME/.gnupg/sks-keyservers.netCA.pem - - -resolve 'hkps.pool.sks-keyservers.net:443:176.9.51.79' "https://hkps.pool.sks-k eyservers.net/pks/lookup?op=stats" * Added hkps.pool.sks-keyservers.net:443:176.9.51.79 to DNS cache * Hostname was found in DNS cache * Trying 176.9.51.79... * Connected to hkps.pool.sks-keyservers.net (176.9.51.79) port 443 (#0) * Initializing NSS with certpath: none * CAfile: /home/kristianf/.gnupg/sks-keyservers.netCA.pem CApath: none * SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 * Server certificate: * subject: E=admin at sks.karotte.org,CN=sks.karotte.org,O=sks.karotte.org,C= DE * start date: Nov 07 12:35:30 2014 GMT * expire date: Nov 07 12:35:30 2015 GMT * common name: sks.karotte.org * issuer: CN=sks-keyservers.net CA,O=sks-keyservers.net CA,ST=Oslo,C=NO > GET /pks/lookup?op=stats HTTP/1.1 User-Agent: curl/7.39.0 Host: > hkps.pool.sks-keyservers.net Accept: */* > ---------------snip---------------< using sks.karotte.org (works using CA Cert) $ curl -vv "https://sks.karotte.org/pks/lookup?op=stats" * Hostname was NOT found in DNS cache * Trying 176.9.51.79... * Connected to sks.karotte.org (176.9.51.79) port 443 (#0) * Initializing NSS with certpath: none * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none * SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 * Server certificate: * subject: CN=*.karotte.org * start date: Apr 18 10:59:40 2014 GMT * expire date: Apr 17 10:59:40 2016 GMT * common name: *.karotte.org * issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. > GET /pks/lookup?op=stats HTTP/1.1 User-Agent: curl/7.39.0 Host: > sks.karotte.org Accept: */* ---------------snip---------------< using alita.karotte.org (connects using CAcert, no sks service so returns 404): > ---------------snip---------------< 404 Not Found

Not Found

The requested URL /pks/lookup was not found on this server.

> ---------------snip---------------< And dirmngr log: > ---------------snip---------------< 2014-11-14 13:59:19 dirmngr[5952.0] DBG: chan_0 <- KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net ... 2014-11-14 13:59:23 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:23 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:23 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:23 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:23 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:23 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:23 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:23 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:23 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:23 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:23 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:23 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:23 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:23 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:23 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:23 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:23 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:23 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:23 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:23 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:23 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:23 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:23 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:23 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:23 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:23 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:23 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:23 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:23 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:23 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:24 dirmngr[5952.0] TLS verification of peer failed: status=0x0042 2014-11-14 13:59:24 dirmngr[5952.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:24 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:24 dirmngr[5952.0] TLS verification of peer failed: status=0x0042 2014-11-14 13:59:24 dirmngr[5952.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:24 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:24 dirmngr[5952.0] TLS verification of peer failed: status=0x0042 2014-11-14 13:59:24 dirmngr[5952.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:24 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:24 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:24 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:24 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:24 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:24 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:24 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:24 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:24 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:25 dirmngr[5952.0] TLS verification of peer failed: status=0x0042 2014-11-14 13:59:25 dirmngr[5952.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2014-11-14 13:59:25 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:25 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:25 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:25 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:25 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:25 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:25 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:25 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:25 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:25 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:25 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:25 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:25 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:25 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:25 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:25 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:25 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:25 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:25 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:25 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:25 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:25 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:25 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:25 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:25 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:25 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:25 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:25 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:25 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:25 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:26 dirmngr[5952.0] TLS verification of peer failed: status=0x0042 2014-11-14 13:59:26 dirmngr[5952.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2014-11-14 13:59:26 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:26 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:26 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:26 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:26 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:26 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:26 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:26 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:26 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:26 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:26 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:26 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:26 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:26 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:26 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:26 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:26 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:26 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:26 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:26 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:26 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:26 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:26 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:26 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:26 dirmngr[5952.0] TLS verification of peer failed: status=0x0042 2014-11-14 13:59:26 dirmngr[5952.0] TLS verification of peer failed: The certificate is NOT trusted. The certificate issuer is unknown. 2014-11-14 13:59:26 dirmngr[5952.0] DBG: expected hostname: alita.karotte.org 2014-11-14 13:59:26 dirmngr[5952.0] DBG: BEGIN Certificate 'server[0]': 2014-11-14 13:59:26 dirmngr[5952.0] DBG: serial: 02326A 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notBefore: 2014-04-18 10:59:40 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notAfter: 2016-04-17 10:59:40 2014-11-14 13:59:26 dirmngr[5952.0] DBG: issuer: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:26 dirmngr[5952.0] DBG: subject: CN=*.karotte.org 2014-11-14 13:59:26 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.13 2014-11-14 13:59:26 dirmngr[5952.0] DBG: SHA1 fingerprint: 7B587956C292593511947904CD88937BC4B610BB 2014-11-14 13:59:26 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:26 dirmngr[5952.0] DBG: BEGIN Certificate 'server[1]': 2014-11-14 13:59:26 dirmngr[5952.0] DBG: serial: 00 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notBefore: 2003-03-30 12:29:49 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notAfter: 2033-03-29 12:29:49 2014-11-14 13:59:26 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:26 dirmngr[5952.0] DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:26 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.4 2014-11-14 13:59:26 dirmngr[5952.0] DBG: SHA1 fingerprint: 135CEC36F49CB8E93B1AB270CD80884676CE8F33 2014-11-14 13:59:26 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:26 dirmngr[5952.0] DBG: BEGIN Certificate 'server[2]': 2014-11-14 13:59:26 dirmngr[5952.0] DBG: serial: 0A418A 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notBefore: 2011-05-23 17:48:02 2014-11-14 13:59:26 dirmngr[5952.0] DBG: notAfter: 2021-05-20 17:48:02 2014-11-14 13:59:26 dirmngr[5952.0] DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA 2014-11-14 13:59:26 dirmngr[5952.0] DBG: subject: CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert Inc. 2014-11-14 13:59:26 dirmngr[5952.0] DBG: hash algo: 1.2.840.113549.1.1.11 2014-11-14 13:59:26 dirmngr[5952.0] DBG: SHA1 fingerprint: AD7C3F64FC4439FEF4E90BE8F47C6CFA8AADFDCE 2014-11-14 13:59:26 dirmngr[5952.0] DBG: END Certificate 2014-11-14 13:59:26 dirmngr[5952.0] TLS connection authentication failed: General error 2014-11-14 13:59:26 dirmngr[5952.0] error connecting to 'https://alita.karotte.org:443': General error 2014-11-14 13:59:26 dirmngr[5952.0] command 'KS_GET' failed: General error 2014-11-14 13:59:26 dirmngr[5952.0] DBG: chan_0 -> ERR 1 General error 2014-11-14 13:59:26 dirmngr[5952.0] DBG: chan_0 <- BYE 2014-11-14 13:59:26 dirmngr[5952.0] DBG: chan_0 -> OK closing connection 2014-11-14 13:59:26 dirmngr[5952.0] handler for fd 0 terminated > ---------------snip---------------< - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Knowing is not enough; we must apply. Willing is not enough; we must do." (Johann Wolfgang von Goethe) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUZgHoAAoJEPw7F94F4TagbIIP/1GToztHnstSfz8xklgNKY8x IUY0YZ9OLfYu2TFjYN7E/6Scrh2l5OTxxlHKmZ9MpaWQ5ah/mFZc5KC6ZrKpVm5v PhMVlZRnqDXUbn7CYaBwvTSsY05G6/ifa/dCtt2Zr08IM7ReUDP97m/tdH3rOm7f IDNGJLcxxt2vhgzB2+CJuzNirCKEYqHylkI4+30UHXAb8D/ME4B16wGxgT0+OHpL 0fg6jxZMnjJ6YWRHOatoMyEhGtcayJc74b37dMzNr8TzowVTvBMnB+Pvy81/ROgd 7jMmdeO732zxVjXUssedcQOK/6mydr75LKCA82gEZE8TcFHm1/q2LZ+6NEaIHX8Y FYuGeZV4/kyJt/5aI7gLcygtxNIrbRIlFsLZgjdzzFCD+UzNlBxkzl+jqAKemKBs LzE2Hdryiuy081wFIugRUtWKOxaneDn7H03XxrqVvvIWN2TZC62wkvX5zE2fSjGD 4OYnL1yZO3wK5Wkk0rWpuPGVcABewmWLKDJ6NuYjTpSTkoWqSXC5+2ZV5PEuG+Es JCqogS+hW9H41bX70sbPWKQhQQ0HQxNOAhQDg1DSbSF3cxrlNJ0RrzOM1+4ABY6k VZGqSgFiaeaGgenudfsXEgDy92co0i4jH29Y/8YL4cldwWvDqmFY82ec/Ng3/MnO vC5TxJq6y1BsiBb5bRn8 =pDmu -----END PGP SIGNATURE----- From johanw at vulcan.xs4all.nl Fri Nov 14 14:31:40 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 14 Nov 2014 14:31:40 +0100 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <5466043C.6090201@vulcan.xs4all.nl> On 14-11-2014 13:24, david at gbenet.com wrote: > I have cooled. You can export your private key - you can export your public key. I've never done that, except when I imported my old pgp 2.x keys in GnuPG a long time ago (sometime when GnuPG became really usable on windows, with 1.0.4 or so). Exporting and re-importing keys can often lead to warnings about thrust issues. I just copied pubring.gpg, secring.gpg, trustdb.gpg and gpg.conf. The last one sometimes required manual editing, especially in the time when IDEA and RSA were loadable modules, but that's long over. Sometimes the owner/group and properties need to be set but my experience is that GnuPG complains clearly when you do that wrong (importing a key while pubring is not writable will fail of course). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From gabriel.niebler at gmail.com Fri Nov 14 14:38:57 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Fri, 14 Nov 2014 14:38:57 +0100 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <546605F1.6060903@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear David, dear fellow GnuPG users, this conversation made me curious, so I tried to do it myself. Here's what I did on my work laptop, just now, five minutes ago (in my home dir): $ rm -rf .gnupg $ scp -r ${myfileserver}:${pathtobackupsfromOTHERlaptop}/.gnupg/ . (...) $ rm .gnupg/random_seed $ echo "My hovercraft is full of fish, but I tell everyone they're eels." > my_big_secret.txt $ gpg --encrypt --recipient 0x65A3F1CC8303C0EC my_big_secret.txt $ rm my_big_secret.txt $ gpg --decrypt my_big_secret.txt.gpg You need a passphrase to unlock the secret key for user: "Gabriel Niebler " 2048-bit RSA key, ID 0x65A3F1CC8303C0EC, created 2014-03-16 (subkey on main key ID 0xD05AF6C786CB34F4) gpg: encrypted with 2048-bit RSA key, ID 0x65A3F1CC8303C0EC, created 2014-03-16 "Gabriel Niebler " My hovercraft is full of fish, but I tell everyone they're eels. So this all worked and the fact that this message is signed (using Enigmail/Thunderbird) is further proof that the method worked for me. Now that we have established that simply copying over your .gnupg directory from one machine to another and deleting random_seed does indeed produce the desired result for some people, maybe you can walk us through exactly what you did and we'll see if we can't figure out what the problem is. I suggest copying and pasting shell commands and their output verbatim. If you do not want to bother the rest of the list with this you are welcome to send mails directly to me. I am not an expert, but I'm willing to help you. Best gabe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJUZgXnAAoJEO7XEikU4kSz93IH/19F+c4ED9L+XesojRuD0Svs OEwcm6GJHpc3QvTfIbhpwbJdOzcrAX49SD/bqw9stBYY+CO3Zf6oo0ANbqtTwZUd 0kMbxz9gtjNqFW7xfVZOpRpNqhUZ/Rob1msTZT2pmw3Jl2iqVIT3VgYIA5hGsy30 LFsH8ROg3ksMTcyukLoN/Ihe/j0W/zz96xy53lDyb8ASuX1xf6oFSVWpqmWrz4xK 9UO2EV1WNZyl8BGwPMbcmqCjResi7l0zZ5bnQ7YUxs0wb9yj/Dke/Erl75wFPezK GQcjUT4d9fJ56sgDQ2V8AUJ0LMMt/FoeFIF7d0DKxANUjS1EBNHhEWnwmQVDZjo= =IuI2 -----END PGP SIGNATURE----- From martin-gnupg-users at dkyb.de Fri Nov 14 16:01:15 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Fri, 14 Nov 2014 16:01:15 +0100 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <5466193B.2040708@dkyb.de> Am 14.11.2014 um 13:24 schrieb david at gbenet.com: > I have cooled. > [...] > Sure you can moan criticise me for my getting frustrated - and you can all moan and cringe > and all withdraw your support - BUT NO ONE HAS EVER OFFERED ANY PRACTICAL USEFUL ADVICE THAT > WILL ENABLE ME TO TRANSFER MY KEYS AND HAVE THEM WORKING CORRECTLY. NO ONE. NOT EVEN YOU. > Aha, so that is cooled? Okay, maybe I wasn't clear. I will extend my advise. Shut up. Cool Down. Cool Down more. Start writing. If your write yourself into rage again, go back to cooling and DON'T hit the send button. > You are offended? Why? It is an easy thing to do is it not to moan about what and how people > express themselves - yet you completely ignore the real issue. 1. I'm offended because you act like a little kid and miss judge the work of others, just because you have a small problem with a part of the work. And if that is not enough you blame others just because the most likely cause for the problems you are having is YOU. 2. I'm offended because you state your little narrow view of the world as fact. 3. I'm offended that you are to lazy to give a detailed report of what commands you use, what the output is. What messages you get. No chance for anyone to reproduce the problem. Just demands from you, negating all the support and help people tried to give you. But I have not seen a single sign, that you thought about, what you can do, so it easier for others to help. So please don't give me that crap with "how people express themselves". And I hope point 3 is close enough to the real issue for you. If you get till here, I hope the above part is from it's "tune" close enough to how you communicate, so you get an impression how your mails appear to others. Now comes a little more productive part. Here are some questions which might get you on track: People told you that c/p the .gnupg directory is the easiest solution and worked for them. Your wrote you used import/export commands. Why that and not the c/p solution? Which keys did you want to export/import via command line? Just your private key? And please take above point 3 into consideration. Without a detailed step by step instruction (with commands, ...) which leads to the problem at least I am out. I can just tell you that I just successfully created a private key, exported it, imported it with an outdated (portable) gnupg version and used it with no problems. Martin From philip.jackson at nordnet.fr Fri Nov 14 16:01:59 2014 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Fri, 14 Nov 2014 16:01:59 +0100 Subject: Fermi estimates In-Reply-To: <54656AB2.2070802@sixdemonbag.org> References: <546565B5.3040107@sixdemonbag.org> <54656AB2.2070802@sixdemonbag.org> Message-ID: <54661967.30201@nordnet.fr> On 14/11/14 03:36, Robert J. Hansen wrote: > Whoops! >> so 10**30 years. The universe is about 10 billion years old, or >> 10**13 years, so ... our brute-force key cracker takes 10**17 times >> longer than the age of the universe in order to brute-force a 128-bit >> key. > > 10 billion is 10**10, so it takes 10**20 times the age of the universe. > But at some point, who's counting? > >> Admittedly, that energy gets released over 10**13 times the age of >> the universe... > > 10**20. > Thanks for that (and the previous).... It makes the brain hurt but raises a few questions in my mind. Does anything prevent the key breaker getting lucky and cracking it first try? It seems to me that all discussions on key breaking with their very large numbers always assume that the last try is THE ONE. And how does the cracker know he has succeeded ? Does he have to pause between each iteration to see if he has 'something good' ? And in the 10**38 key attempts, what's the chance of having multiple apparently 'GOOD ONES' ? Perhaps a double bluff is needed : send the message in plain text with just a hint that it might be encrypted ? Philip From rjh at sixdemonbag.org Fri Nov 14 16:22:14 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 14 Nov 2014 10:22:14 -0500 Subject: Fermi estimates In-Reply-To: <54661967.30201@nordnet.fr> References: <546565B5.3040107@sixdemonbag.org> <54656AB2.2070802@sixdemonbag.org> <54661967.30201@nordnet.fr> Message-ID: <54661E26.8030905@sixdemonbag.org> > Thanks for that (and the previous).... It makes the brain hurt but > raises a few questions in my mind. The real purpose of a Fermi estimate isn't to give you solid answers: it's to give you an appreciation of the problem. If it does that, it's done its job. (Also, a listmember named Ineiev points out that I *may* be misapplying the Margolus-Levitin theorem. It's ... interesting. I need to think on it for a while. The objection is basically, "that much energy has to be present, but not necessarily released as heat: Landauer still applies. You need something really energetic, but that energy might not be world-ending." I don't know: I need to think about that. :) ) > Does anything prevent the key breaker getting lucky and cracking it > first try? Nope. The odds are considerably worse than the lottery, though. > It seems to me that all discussions on key breaking with their very > large numbers always assume that the last try is THE ONE. The assumption is the key is broken after exhausting 50% of the keyspace. > And how does the cracker know he has succeeded ? We're assuming the cracker has a crib -- a known message header or something similar. This is usually a safe assumption to make. > Does he have to pause between each iteration to see if he has > 'something good' ? Checking takes time, yes. > And in the 10**38 key attempts, what's the chance of having multiple > apparently 'GOOD ONES' ? Infinitesimal. From rjh at sixdemonbag.org Fri Nov 14 16:32:51 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 14 Nov 2014 10:32:51 -0500 Subject: Why the software is crap In-Reply-To: <5465F47A.2000709@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> Message-ID: <546620A3.8020400@sixdemonbag.org> > No one. No one. No one knows how to do this simple task. (a) delete random_seed (b) copy your .gnupg directory over I don't see the problem. I've done this at least fifty different times in the last year as I've stood up virtual machines. If you'd like a copy of the Python script I use to do this quickly, say the word. It probably won't be useful for you unless you stand up a lot of virtual machines, but... > As I have said no one has ever successfully transferred their public > and private keys between machines and got them to successfully work. > That's a real fact. And no one on this list as any practical > solutions that work in the real world. That's a fact. The fact is no > one on this list has ever done it with 100 per cent success. That's a > fact. These are not facts. Take a deep breath. There are people here who want to help you, people who have successfully done what you want to do. Keep a cool head and work the problem. Let's not make matters worse with harsh words, okay? From johanw at vulcan.xs4all.nl Fri Nov 14 16:48:14 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 14 Nov 2014 16:48:14 +0100 Subject: Fermi estimates In-Reply-To: <54661967.30201@nordnet.fr> References: <546565B5.3040107@sixdemonbag.org> <54656AB2.2070802@sixdemonbag.org> <54661967.30201@nordnet.fr> Message-ID: <5466243E.7020007@vulcan.xs4all.nl> On 14-11-2014 16:01, Philip Jackson wrote: > Does anything prevent the key breaker getting lucky and cracking it first try? No. It's just extremely unlikely. > It seems to me that all discussions on key breaking with their very large > numbers always assume that the last try is THE ONE. Nu, usually one assumes that brute forcing requires, on average, scanning half the keyspace. > And how does the cracker know he has succeeded ? That's the tricky part. If the output of the encryption program is just encrypted text, the only way is to see if there's something recognizable in the decrypted stuff. But most software includes some kind of CRC check or a hash so that can be checked. GnuPG does this. > Does he have to pause between > each iteration to see if he has 'something good' ? Yes. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From alexanderino at gmail.com Fri Nov 14 16:28:26 2014 From: alexanderino at gmail.com (Jason Antony) Date: Sat, 15 Nov 2014 02:28:26 +1100 Subject: Help needed In-Reply-To: <546531BB.2000206@gbenet.com> References: <546531BB.2000206@gbenet.com> Message-ID: <54661F9A.9010305@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-14 09:33, david at gbenet.com wrote: > But I get the following error when signing my mail: "Key 0xAAd8C47D > not found or not valid. The (sub-)key might have expired." The key > is visible in Enigmail Kgpg Kleopatra GPA I'm not able to edit my > key I can't enter my passphrase. The solution may be to re-install pinentry, as described here: http://baitisj.blogspot.com.au/2014/07/enigmail-key-not-found-or-not-valid.html Let us know how you go. Cheers, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUZh+YAAoJED1Q2DsLuMaGmYIP/RzDDFeaFVwqxAHx/cROIqmF wUCMY+IuXfO8XfWhggDUJ6u7j0EChuAe6lXjpc59YgkmQXCeyOofVgMw0F2ml/lM amvxOFJk2EO+nAoqvzeCyaEhb1RhO/x4nZyF4/3PgvEHs/J38PqLL1MNmJ4phXLJ MweGuwxGgqP+jB4lZNoTzZ0/cXFneCdV7sgLyycIBFldNGlSB9q/8n+N/6N8zeTu 7c22yTCQYan1T/l1YP/MsYXLm1gWfgEDHUR7e0nkvch0bHLyYVqSKrUdkLxAL0+p cPb7x6TMYvmd0gPX4yjAFVYLOmoV2RYOS6j34UCsqIuSSJhT+N82r6/ReLolz+hC EuFF4vr4DLcrV6ASNeoSmhiDmKhwbzH05pHbziPxrUWMfDag6ve80HAeBF9bT4jy bg+H9QZ1NOqjOgu4y+f0ueigOtvhSA4vAeFjjgarHCXirkXFzgpYJVovqXRapOyE rO5J79cxBJmUkG4rMlt18GfvX+bzjwfu3aDd3NFFNiKajTTymGtWjmkuVNkZ36Yp r+JRwfgIYdKVTGztEHzThCgF7ljo4qYtExvU79ZqVGpFrSsXiQ/pPx837PlEOdKN Wu7ZksZIv6dJFGVXTkx34EiOkQfzm/yvCKwXyRS38jxjB4c6cCQIT7zfir962/Oz frRWGclfUsgb+I6m1JF9 =hUx5 -----END PGP SIGNATURE----- From vedaal at nym.hush.com Fri Nov 14 18:02:47 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 14 Nov 2014 12:02:47 -0500 Subject: gpg4usb: Portable GUI for GnuPG In-Reply-To: <54652F6B.2020905@sixdemonbag.org> References: <54648C0D.6000307@roembden.net> <54652F6B.2020905@sixdemonbag.org> Message-ID: <20141114170247.44B882038F@smtp.hushmail.com> On 11/13/2014 at 5:23 PM, "Robert J. Hansen" wrote: >Putting it on CD-ROM might be a pretty cool idea ===== It's already been done by UPR. https://www.privacy-cd.org/en It uses Ubuntu 12.04 with GnuPG and pre-7.2 Truecrypt already installed. (open source roll-your-own available). I've tried it a few times and found it interesting, in that I couldn't access anything on the host computer's hard disc, or go online, features instituted to protect the UPR user, but also protects the host computer, (and makes it easier to get permission to *borrow* a frend's laptop to do some work on files on my usb ;-) ) Anyone here have any experience with it? TIA, vedaal From david at gbenet.com Fri Nov 14 18:05:12 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:05:12 +0000 Subject: Help needed In-Reply-To: <54661F9A.9010305@gmail.com> References: <546531BB.2000206@gbenet.com> <54661F9A.9010305@gmail.com> Message-ID: <54663648.6040005@gbenet.com> On 14/11/14 15:28, Jason Antony wrote: > On 2014-11-14 09:33, david at gbenet.com wrote: > >> But I get the following error when signing my mail: "Key 0xAAd8C47D >> not found or not valid. The (sub-)key might have expired." The key >> is visible in Enigmail Kgpg Kleopatra GPA I'm not able to edit my >> key I can't enter my passphrase. > > The solution may be to re-install pinentry, as described here: > > http://baitisj.blogspot.com.au/2014/07/enigmail-key-not-found-or-not-valid.html > > Let us know how you go. > > Cheers, > > Jason > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I get: david at laptop-1:~$ sudo pkg install pinentry-gtk2 [sudo] password for david: sudo: pkg: command not found david at laptop-1:~$ sudo apt-get install pinentry-gtk2 Reading package lists... Done Building dependency tree Reading state information... Done pinentry-gtk2 is already the newest version. pinentry-gtk2 set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. david at laptop-1:~$ So that's a complete failure David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:10:10 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:10:10 +0000 Subject: Why the software is crap In-Reply-To: <5465EBDB.5060701@gmail.com> References: <5465EA7A.2050005@gbenet.com> <5465EBDB.5060701@gmail.com> Message-ID: <54663772.4020704@gbenet.com> On 14/11/14 11:47, NdK wrote: > Il 14/11/2014 12:41, david at gbenet.com ha scritto: > > I usually just lurk, but that's too much... > >> I even tried exporting my private and public key from the command line and then tried >> importing. The same error message as before. I have checked on the internet - most of the >> suggestions are crap - the authors have never ever tried to do what they suggest others to >> do. If they had done so then they would have known just how crappy their supposed >> expertise was. >> I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a >> useless pile of crap also. > Surely you're doing it wrong, overlooking some passage. So don't blame others for something > *you* are doing wrong. > >> I am faced with two options: >> (1) Create yet another set of keys >> (2) Give up using gnupg after some 20 years > (3) Do it the right way as everyone else and admit you were doing something wrong. > >> I think I will unsubscribe from this list and give up on gnupg as a pile of crap. > And that will be better for the whole community. > > BYtE, > Diego. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Another completely pointless response David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:11:34 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:11:34 +0000 Subject: My Conclusions In-Reply-To: <5465EE02.9090402@kernelconcepts.de> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> <5465EE02.9090402@kernelconcepts.de> Message-ID: <546637C6.6050101@gbenet.com> On 14/11/14 11:56, Nicole Faerber wrote: > Oh please, I am using gnupg with the same keys on at least five > machines with no issue. > > I simply copied the .gnupg directory, end of story. > > Cheers > nicole > > > Am 14.11.2014 um 12:45 schrieb david at gbenet.com: >> On 14/11/14 11:34, Nicholas Cole wrote: >>> David, >>> >>> I'm sorry you are having problems, but I think this is just >>> nonsense. Of course people move keys between machines all the >>> time. I have done it myself often. I don't think that anyone >>> deserves that level of abuse -- certainly not someone who has put >>> years of work into a program that is an industry standard and >>> released it for free. >>> >>> Nicholas >>> >>> On Fri, Nov 14, 2014 at 10:42 AM, david at gbenet.com >>> wrote: >>>> Hi All, >>>> >>>> After spending 62 hours on what I thought would be a simple >>>> task namely to get a fully functioning gnupg mirror on my 64 >>>> bit Linux system - I realise this is an impossible task to do. >>>> In the past I've ended up creating a new set of certificates - >>>> but this time round I thought that I would apply some effort. >>>> >>>> My conclusion is It IS Impossible To Transfer Your Keys From >>>> The Same O/S To Another Machine. >>>> >>>> There is no one in the entire universe that has ever attempted >>>> it. And if they have THEY HAVE FAILED. Not one person on this >>>> list knows how to do it successfully. No one. NOT ONE OF YOU >>>> can transfer a mirror image of your .gnupg folder and expect it >>>> to work. >>>> >>>> This tells me what I have long suspected - yes it's good at >>>> encryption and signing but the programme is fundamentally >>>> flawed as to make it utter crap. My keys are PERFECT but the >>>> software is CRAP. Werner Koch knows it's crap. Every one knows >>>> it's crap. >>>> >>>> So, If I want to go on signing and encrypting my emails I HAVE >>>> TO CREATE ANOTHER SET A BLOODY KEYS!!!!!!!! >>>> >>>> I am not a happy bunny!!! >>>> >>>> David >>>> >>>> >>>> >>>> >>>> -- ?See the sanity of the man! No gods, no angels, no demons, >>>> no body. Nothing of the kind.Stern, sane,every brain-cell >>>> perfect and complete even at the moment of death. No delusion.? >>>> https://linuxcounter.net/user/512854.html - http://gbenet.com >>>> >>>> _______________________________________________ Gnupg-users >>>> mailing list Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >>> _______________________________________________ Gnupg-users >>> mailing list Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >> I have done everything correctly - and my conclusions are still the >> same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR >> .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION >> PROGRAMME THAT WORKS. > >> THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU >> HAVE NEVER EVER DONE IT. > >> David > > > > > Viele Gr??e > nicole faerber > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > That does not work David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:13:11 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:13:11 +0000 Subject: My Conclusions In-Reply-To: <5465F259.2030106@gmail.com> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> <5465F259.2030106@gmail.com> Message-ID: <54663827.4070206@gbenet.com> On 14/11/14 12:15, Jason Antony wrote: > On 2014-11-14 22:45, david at gbenet.com wrote: > >> I have done everything correctly - and my conclusions are still >> the same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR >> .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION >> PROGRAMME THAT WORKS. > > But many have succeeded in it. Add myself to the list of people who > have successfully backed up and re-used my GPG data files for over ten > years, across various operating systems. > > It would be best to re-visit the problem when you're in a clear, calm > frame of mind. > > All the best, > > Jason > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Another pointless answer - no practical data - so there's no validity in what you say David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:14:59 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:14:59 +0000 Subject: Why the software is crap In-Reply-To: <4120517.Z87MTM4IoF@forge> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <4120517.Z87MTM4IoF@forge> Message-ID: <54663893.7020900@gbenet.com> On 14/11/14 12:37, Samir Nassar wrote: > David, > > It might not be clear, but many of us have easily and simply migrated our > .gnupg directories from computer to computer. > > I've even deleted my .gnupg directory and restored it from backups. I've > intentionally messed up my private key and restored my private key to working > status from backups. > > I guess I don't understand why you can't copy .gnupg from one system to > another system. > > Yelling on the mailing list is extremely rude. It is now very clear, and > archived, how you feel about the topic. Repeating yourself further in the > manner you have been using will only alienate people and will not move you to > a resolution. > > You've registered your complaint, it has been discussed, and now your behavior > is counter-productive. > > Samir > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Backups don't work there are no practical solutions and therefor what you say haS NO VALIDITY David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:16:40 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:16:40 +0000 Subject: Why the software is crap In-Reply-To: <5465F868.7040303@internexusconnect.net> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <5465F868.7040303@internexusconnect.net> Message-ID: <546638F8.6000403@gbenet.com> On 14/11/14 12:41, Tristan Santore wrote: > On 14/11/14 13:24, david at gbenet.com wrote: >> On 14/11/14 11:55, Martin Behrendt wrote: >>> Am 14.11.2014 um 12:41 schrieb david at gbenet.com: >>>> Hello All, >>>> >>>> I even tried exporting my private and public key from the command line and then tried >>>> importing. The same error message as before. I have checked on the internet - most of the >>>> suggestions are crap - the authors have never ever tried to do what they suggest others to >>>> do. If they had done so then they would have known just how crappy their supposed >>>> expertise was. >>>> >>>> I have even looked through https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a >>>> useless pile of crap also. >>>> >>>> I am faced with two options: >>>> >>>> (1) Create yet another set of keys >>>> (2) Give up using gnupg after some 20 years >>>> >>>> I think I will unsubscribe from this list and give up on gnupg as a pile of crap. >>>> >>>> David >>>> >>> >>> I think unsubscribing is the best thing you can do. Because you probably >>> successfully destroyed the good intension and motivation of anyone >>> helping you, with the offending nonsense you wrote in your last mails. >>> >>> If you are angry just shut up and write again after you cooled yourself >>> down. The problem is more likely with you because there are not many >>> people reporting such problems. >>> And I can tell from my own experience that it is not even a problem >>> copying the content of the gnupg directory between windows and linux. >>> Tried that successfully. >>> Maybe you should read the FAQ again (and try to understand what is >>> written). Maybe there is a difference between exporting the public part >>> of a key and the private part. >>> >>> Anyway, enjoy your life. >>> Martin >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> >> Martin, >> >> I have cooled. You can export your private key - you can export your public key. You can >> import your private key you can import your public key. In 20 years I have always had the >> same problem - the same error message and have each time created a new set of keys. I have >> done this 4 times. >> >> I notice that no one on this list - for all the talk of "oh I've done it" can offer no >> practical information has to HOW. No one. No one. No one knows how to do this simple task. >> In all my 20 years I have never found out how. Perhaps things are different under a Windows >> O/S but on Linux there is NO SOLUTION. >> >> Perhaps the only "solution" is to import ones private and public keys and lose all your >> contacts - ie a brand new installation. But I repeat BUT no one has ever created a mirror >> image of a .gnupg and had a fully 100 per cent working signing and encryption functionality. >> No one. There are no real practical solutions written anywhere on the internet. >> >> There is nothing of any value in https://www.gnupg.org/faq/GnuPG-FAQ.html - there never was >> in all the 20 years of reading it. >> >> Sure you can moan criticise me for my getting frustrated - and you can all moan and cringe >> and all withdraw your support - BUT NO ONE HAS EVER OFFERED ANY PRACTICAL USEFUL ADVICE THAT >> WILL ENABLE ME TO TRANSFER MY KEYS AND HAVE THEM WORKING CORRECTLY. NO ONE. NOT EVEN YOU. >> >> You are offended? Why? It is an easy thing to do is it not to moan about what and how people >> express themselves - yet you completely ignore the real issue. You ignore is because you can >> offer no real meaningful solution. As I have said no one has ever successfully transferred >> their public and private keys between machines and got them to successfully work. That's a >> real fact. And no one on this list as any practical solutions that work in the real world. >> That's a fact. The fact is no one on this list has ever done it with 100 per cent success. >> That's a fact. There is no practical advice on the internet. That's a fact. >> >> David >> >> > David, > > I am pretty sure I have seen advice on how to backup and restore your keys, if not on this > list, in the countless smartcard how to. > > I must admit I have not followed previous threads from you, but you must admit and be fair, > that generally most people here are friendly and supportive. But I have seen the topic come > up a few times, so maybe this is a security versus usability issue ? But again, I have not > followed exactly what your problem is. Just wanted to point out that most people are > reasonably helpful and friendly. Labelling gnupg as crap is, not exactly a fair assessment I > think, and falls within the lines of labelling selinux crap, because people do not > understand it/are confused by what is going on. > > Anyway. I hope you work it out in the end and I am sure, somebody will be willing yo nudge > you in the right direction. > > Regards, > > Tristan > Another pointless response David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:19:12 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:19:12 +0000 Subject: My Conclusions In-Reply-To: <87tx22t0fp.fsf@vigenere.g10code.de> References: <5465DC99.3060803@gbenet.com> <87tx22t0fp.fsf@vigenere.g10code.de> Message-ID: <54663990.5020109@gbenet.com> On 14/11/14 12:46, Werner Koch wrote: > On Fri, 14 Nov 2014 12:34, nicholas.cole at gmail.com said: > >> I'm sorry you are having problems, but I think this is just nonsense. >> Of course people move keys between machines all the time. I have done > > Right. And you may even copy it from one OS to an entirely different > one. The files are fully platform independent. > > Yet another of these gnome-keyring-daemon problems? > > > Salam-Shalom, > > Werner > Werner, I have done everything - but have a complete and absolute failure. Nothing works - I get the same error time and time again. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:24:21 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:24:21 +0000 Subject: Why the software is crap In-Reply-To: <5465FF8B.4000508@gmail.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <5465FF8B.4000508@gmail.com> Message-ID: <54663AC5.50500@gbenet.com> On 14/11/14 13:11, NdK wrote: > Il 14/11/2014 13:24, david at gbenet.com ha scritto: > >> I have cooled. You can export your private key - you can export your public key. You can >> import your private key you can import your public key. In 20 years I have always had the >> same problem - the same error message and have each time created a new set of keys. I have >> done this 4 times. > If all four times you did the same wrong thing, then it's obvious that you got the same > wrong result. > > Just to prove it's your error, I copied my .gnupg from one system (str957-142) to another > (str957-004), with the most basic method I ould think of. I'm not an expert (probably I > transferred more than what was needed!), but as you can see I succeeded at the first try! > > diego at str957-142:~$ gpg --list-secret-keys > /home/diego/.gnupg/secring.gpg > ------------------------------------------------ > sec 2048R/F9B9D307 2014-11-14 > uid Diego > ssb 2048R/3A4AD1C0 2014-11-14 > > diego at str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed .gnupg > diego at str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz > > ? necessaria una passphrase per sbloccare la chiave segreta > dell'utente: "Diego " > 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 > > diego at str957-142:~$ ls GnuPG-backup.tar.gz* > GnuPG-backup.tar.gz GnuPG-backup.tar.gz.asc > diego at str957-142:~$ scp GnuPG-backup.tar.gz diego at str957-004:/home/diego > > Then on the other PC: > > diego at str957-004:~$ tar xvfz GnuPG-backup.tar.gz > .gnupg/ > .gnupg/gpg-agent-info > .gnupg/pubring.kbx > .gnupg/gpg.conf > .gnupg/private-keys-v1.d/ > .gnupg/reader_0.status > .gnupg/pubring.gpg~ > .gnupg/secring.gpg > .gnupg/scdaemon.conf > .gnupg/gpa.conf > .gnupg/trustdb.gpg > .gnupg/pubring.gpg > diego at str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz > > ? necessaria una passphrase per sbloccare la chiave segreta > dell'utente: "Diego " > 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 > > diego at str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc > gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID chiave F9B9D307 > gpg: Firma valida da "Diego " > >> I notice that no one on this list - for all the talk of "oh I've done it" can offer no >> practical information has to HOW. No one. No one. No one knows how to do this simple task. >> In all my 20 years I have never found out how. Perhaps things are different under a Windows >> O/S but on Linux there is NO SOLUTION. > Done just now in Ubuntu. So there's an error on your side. > > BYtE, > Diego. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users I have a clean install of 64 bit LXD - all programmes are working 100 per cent. My keys get imported perfectly - every programme including Enigmail knows they are there. But when I try to sign or sign and encrypt I get the error referred too. No amount of copying no amount of backups no amount of anything will change that fact. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:25:37 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:25:37 +0000 Subject: My Conclusions In-Reply-To: <54660043.806@vulcan.xs4all.nl> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> <54660043.806@vulcan.xs4all.nl> Message-ID: <54663B11.5040205@gbenet.com> On 14/11/14 13:14, Johan Wevers wrote: > On 14-11-2014 12:45, david at gbenet.com wrote: > >> I have done everything correctly > > Apparently not. Or maybe the files are corrupted? Do they still work on > the original computer? > >> - and my conclusions are still the same NO ONE HAS EVER >> SUCCESSFULLY MADE A MIRROR COPY OF THEIR .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING >> AND ENCRYPTION PROGRAMME THAT WORKS. > > I did. Switched even between Linux and Windows, no problems. In the > latter case, I did make a few changes to gnupg.conf since Windows has a > different directory structure but that's all. > >> THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU HAVE NEVER EVER DONE IT. > > Stop shouting, we're neither deaf nor blind. > Everything works 100 per cent fine on the other laptop David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:27:01 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:27:01 +0000 Subject: Why the software is crap In-Reply-To: <5466043C.6090201@vulcan.xs4all.nl> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <5466043C.6090201@vulcan.xs4all.nl> Message-ID: <54663B65.7010408@gbenet.com> On 14/11/14 13:31, Johan Wevers wrote: > On 14-11-2014 13:24, david at gbenet.com wrote: > >> I have cooled. You can export your private key - you can export your public key. > > I've never done that, except when I imported my old pgp 2.x keys in > GnuPG a long time ago (sometime when GnuPG became really usable on > windows, with 1.0.4 or so). Exporting and re-importing keys can often > lead to warnings about thrust issues. > > I just copied pubring.gpg, secring.gpg, trustdb.gpg and gpg.conf. The > last one sometimes required manual editing, especially in the time when > IDEA and RSA were loadable modules, but that's long over. > > Sometimes the owner/group and properties need to be set but my > experience is that GnuPG complains clearly when you do that wrong > (importing a key while pubring is not writable will fail of course). > That fails David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Fri Nov 14 18:30:19 2014 From: david at gbenet.com (david at gbenet.com) Date: Fri, 14 Nov 2014 17:30:19 +0000 Subject: Why the software is crap In-Reply-To: <546605F1.6060903@gmail.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <546605F1.6060903@gmail.com> Message-ID: <54663C2B.5040702@gbenet.com> On 14/11/14 13:38, Gabriel Niebler wrote: > Dear David, dear fellow GnuPG users, > > this conversation made me curious, so I tried to do it myself. Here's > what I did on my work laptop, just now, five minutes ago (in my home dir): > > $ rm -rf .gnupg > $ scp -r ${myfileserver}:${pathtobackupsfromOTHERlaptop}/.gnupg/ . > (...) > $ rm .gnupg/random_seed > $ echo "My hovercraft is full of fish, but I tell everyone they're > eels." > my_big_secret.txt > $ gpg --encrypt --recipient 0x65A3F1CC8303C0EC my_big_secret.txt > $ rm my_big_secret.txt > $ gpg --decrypt my_big_secret.txt.gpg > > You need a passphrase to unlock the secret key for > user: "Gabriel Niebler " > 2048-bit RSA key, ID 0x65A3F1CC8303C0EC, created 2014-03-16 > (subkey on main key ID 0xD05AF6C786CB34F4) > > gpg: encrypted with 2048-bit RSA key, ID 0x65A3F1CC8303C0EC, created > 2014-03-16 > "Gabriel Niebler " > My hovercraft is full of fish, but I tell everyone they're eels. > > > So this all worked and the fact that this message is signed (using > Enigmail/Thunderbird) is further proof that the method worked for me. > > Now that we have established that simply copying over your .gnupg > directory from one machine to another and deleting random_seed does > indeed produce the desired result for some people, maybe you can walk > us through exactly what you did and we'll see if we can't figure out > what the problem is. I suggest copying and pasting shell commands and > their output verbatim. > > If you do not want to bother the rest of the list with this you are > welcome to send mails directly to me. I am not an expert, but I'm > willing to help you. > > Best > gabe > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > I tried this with my keys - it was successful - I even imported my keys successfully but I get the same error as before. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From nicholas.cole at gmail.com Fri Nov 14 18:30:41 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 14 Nov 2014 17:30:41 +0000 Subject: My Conclusions In-Reply-To: <546637C6.6050101@gbenet.com> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> <5465EE02.9090402@kernelconcepts.de> <546637C6.6050101@gbenet.com> Message-ID: David, I've read most of your emails about this, and I don't see any description of the command you have entered or the error you are getting. Trying to diagnose "it doesn't work" error reports is a little like trying to type blind: you might get it right, but you'll probably just frustrate anyone trying to read what you've written. The standard way to report errors is: 1. What are you trying to do? 2. What command(s) did you enter exactly? 3. What did you expect to see? 4. What did you actually see? So far, I can only see the answer to question 1. N. On Fri, Nov 14, 2014 at 5:11 PM, david at gbenet.com wrote: > On 14/11/14 11:56, Nicole Faerber wrote: >> Oh please, I am using gnupg with the same keys on at least five >> machines with no issue. >> >> I simply copied the .gnupg directory, end of story. >> >> Cheers >> nicole >> >> >> Am 14.11.2014 um 12:45 schrieb david at gbenet.com: >>> On 14/11/14 11:34, Nicholas Cole wrote: >>>> David, >>>> >>>> I'm sorry you are having problems, but I think this is just >>>> nonsense. Of course people move keys between machines all the >>>> time. I have done it myself often. I don't think that anyone >>>> deserves that level of abuse -- certainly not someone who has put >>>> years of work into a program that is an industry standard and >>>> released it for free. >>>> >>>> Nicholas >>>> >>>> On Fri, Nov 14, 2014 at 10:42 AM, david at gbenet.com >>>> wrote: >>>>> Hi All, >>>>> >>>>> After spending 62 hours on what I thought would be a simple >>>>> task namely to get a fully functioning gnupg mirror on my 64 >>>>> bit Linux system - I realise this is an impossible task to do. >>>>> In the past I've ended up creating a new set of certificates - >>>>> but this time round I thought that I would apply some effort. >>>>> >>>>> My conclusion is It IS Impossible To Transfer Your Keys From >>>>> The Same O/S To Another Machine. >>>>> >>>>> There is no one in the entire universe that has ever attempted >>>>> it. And if they have THEY HAVE FAILED. Not one person on this >>>>> list knows how to do it successfully. No one. NOT ONE OF YOU >>>>> can transfer a mirror image of your .gnupg folder and expect it >>>>> to work. >>>>> >>>>> This tells me what I have long suspected - yes it's good at >>>>> encryption and signing but the programme is fundamentally >>>>> flawed as to make it utter crap. My keys are PERFECT but the >>>>> software is CRAP. Werner Koch knows it's crap. Every one knows >>>>> it's crap. >>>>> >>>>> So, If I want to go on signing and encrypting my emails I HAVE >>>>> TO CREATE ANOTHER SET A BLOODY KEYS!!!!!!!! >>>>> >>>>> I am not a happy bunny!!! >>>>> >>>>> David >>>>> >>>>> >>>>> >>>>> >>>>> -- ?See the sanity of the man! No gods, no angels, no demons, >>>>> no body. Nothing of the kind.Stern, sane,every brain-cell >>>>> perfect and complete even at the moment of death. No delusion.? >>>>> https://linuxcounter.net/user/512854.html - http://gbenet.com >>>>> >>>>> _______________________________________________ Gnupg-users >>>>> mailing list Gnupg-users at gnupg.org >>>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >>>> _______________________________________________ Gnupg-users >>>> mailing list Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >>> I have done everything correctly - and my conclusions are still the >>> same NO ONE HAS EVER SUCCESSFULLY MADE A MIRROR COPY OF THEIR >>> .GNUPG AND HAD A FULLY 100 PER CENT WORKING SIGNING AND ENCRYPTION >>> PROGRAMME THAT WORKS. >> >>> THERE IS NO CLEAR INSTRUCTIONS FROM ANYONE - SIMPLY BECAUSE YOU >>> HAVE NEVER EVER DONE IT. >> >>> David >> >> >> >> >> Viele Gr??e >> nicole faerber >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > That does not work > > David > > -- > ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No > delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From gabriel.niebler at gmail.com Fri Nov 14 19:24:38 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Fri, 14 Nov 2014 19:24:38 +0100 Subject: Why the software is crap In-Reply-To: <54663C2B.5040702@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <546605F1.6060903@gmail.com> <54663C2B.5040702@gbenet.com> Message-ID: <1ac33c19-ea04-4945-a604-b77e47ccb801@email.android.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear David, On 14. November 2014 18:30:19 MEZ, "david at gbenet.com" wrote: >On 14/11/14 13:38, Gabriel Niebler wrote: >> (...) >> (...) maybe you can walk >> us through exactly what you did and we'll see if we can't figure out >> what the problem is. I suggest copying and pasting shell commands and >> their output verbatim. >> >> If you do not want to bother the rest of the list with this you are >> welcome to send mails directly to me. I am not an expert, but I'm >> willing to help you. (...) >I tried this with my keys - it was successful - I even imported my keys >successfully but I >get the same error as before. Could you please show me exactly what you did, i.e. copy and paste the shell session(s), commands and output. Also, please make it clear which session was run on the origin (where everything works) and which was run on the target (where things don't work). (Feel free to censor whatever you feel is sensisitive info, of course.) I really don't believe I can help you without a clear picture what commands you ran and the output they produced. Don't despair, we'll get it working yet! Best gabe -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFJBAEBCgAzBQJUZkjmLBxHYWJyaWVsIE5pZWJsZXIgPGdhYnJpZWwubmllYmxl ckBnbWFpbC5jb20+AAoJEO7XEikU4kSzeE4H+wXeFGYeazka0Ck3Cy0xch2nX9Xm ySGS8N+/1DrGwotHbQfmnEPqhQzK914897G3p8QCuU8enbaYmq27Kig21iqsGRIW AZNxe9M8aB+WR7oP0YaqmgnM8P/9HykKWCNvNaCLjVZUDSg2JQS1h8WwjYQhTCPe NQY6YYjtK98XewVQKkKR3+HKYYFPMF9cmFvTTihl4fBDfGZUkcBu+u3nZesfX899 ARBXAeHGSNAras13FDkhfydGTq6eQPK14SQ6jhnfQ7S3BnADRegl/szMe4PlLmc5 5A+TQhWvmCt5neWEJYuLKTiHd1H8OaSGkjPimr4XkpGesGHKQJixFvdO+8k= =0lWi -----END PGP SIGNATURE----- From cspitzer at godaddy.com Fri Nov 14 19:20:35 2014 From: cspitzer at godaddy.com (Charles Spitzer) Date: Fri, 14 Nov 2014 18:20:35 +0000 Subject: My Conclusions Message-ID: Speaking as someone who has worked in a computer support organization for over 40 years, I must say you make it extremely hard for someone to help you. You have been asked to provide a list of commands and their output numerous times. You have been provided with some command lines to run, with the expectation that you'd provide the output from those commands. Simply stating "That does not work." does not help anyone help you, and the abuse you have heaped upon people trying to tell you that make them not want to help further. Can you, or can you not, provide a cut/paste of what you are trying to do, which includes the actual command lines you are executing, and the output from the commands that are being executed? Regards, Charlie -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces+cspitzer=godaddy.com at gnupg.org] On Behalf Of david at gbenet.com Sent: Friday, November 14, 2014 10:12 AM To: Nicole Faerber; gnupg-users at gnupg.org Subject: Re: My Conclusions [Charles Spitzer] That does not work David From johannes at zarl.at Fri Nov 14 18:34:07 2014 From: johannes at zarl.at (Johannes Zarl) Date: Fri, 14 Nov 2014 18:34:07 +0100 Subject: Help needed In-Reply-To: <54663648.6040005@gbenet.com> References: <546531BB.2000206@gbenet.com> <54661F9A.9010305@gmail.com> <54663648.6040005@gbenet.com> Message-ID: <3317769.t9jomTh0g7@mani> On Friday 14 November 2014 17:05:12 david at gbenet.com wrote: > david at laptop-1:~$ sudo pkg install pinentry-gtk2 > [sudo] password for david: > sudo: pkg: command not found > david at laptop-1:~$ sudo apt-get install pinentry-gtk2 > Reading package lists... Done > Building dependency tree > Reading state information... Done > pinentry-gtk2 is already the newest version. > pinentry-gtk2 set to manually installed. > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > david at laptop-1:~$ > > So that's a complete failure That seems a little harsh, doesn't it? ;-) After all, you now know that you do indeed have the pinentry-gtk2 installed, and we know that you use a Debian-based distro. Now, you could try to verify that pinentry-gtk2 is the pinentry program that you normally use: $ grep pinentry-program ~/.gnupg/gpg-agent.conf pinentry-program /usr/bin/pinentry-qt4 If not, you should ensure that the right pinentry program for your environment is installed (like you did before with pinentry-gtk2): $ sudo apt-get install pinentry-qt4 If you don't find the cause of the problem in this way, then there's still enough time left to despair if you so wish? Cheers, Johannes From ndk.clanbo at gmail.com Fri Nov 14 21:49:23 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 14 Nov 2014 21:49:23 +0100 Subject: Why the software is crap In-Reply-To: <54663AC5.50500@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <5465FF8B.4000508@gmail.com> <54663AC5.50500@gbenet.com> Message-ID: <54666AD3.5000204@gmail.com> Il 14/11/2014 18:24, david at gbenet.com ha scritto: > I have a clean install of 64 bit LXD - all programmes are working 100 per cent. My keys get > imported perfectly - every programme including Enigmail knows they are there. But when I try > to sign or sign and encrypt I get the error referred too. No amount of copying no amount of > backups no amount of anything will change that fact. Then do what we've already done to try to help you: open a terminal on the source machine, type the commands and cut&paste to the list. Unless you do that, showing *exactly* what you've done, I doubt anybody can help you: all our crystal balls are broken... And I'm *not* going to try to help you again unless I see that cut&paste. Wasted time. BYtE, Diego. From jays at panix.com Fri Nov 14 21:05:46 2014 From: jays at panix.com (Jay Sulzberger) Date: Fri, 14 Nov 2014 15:05:46 -0500 (EST) Subject: Why the software is crap In-Reply-To: <5465EA7A.2050005@gbenet.com> References: <5465EA7A.2050005@gbenet.com> Message-ID: On Fri, 14 Nov 2014, david at gbenet.com wrote: > Hello All, > > I even tried exporting my private and public key from the > command line and then tried importing. The same error message > as before. I have checked on the internet - most of the > suggestions are crap - the authors have never ever tried to do > what they suggest others to do. If they had done so then they > would have known just how crappy their supposed expertise was. > > I have even looked through > https://www.gnupg.org/faq/GnuPG-FAQ.html and found this to be a > useless pile of crap also. > > I am faced with two options: > > (1) Create yet another set of keys > (2) Give up using gnupg after some 20 years > > I think I will unsubscribe from this list and give up on gnupg as a pile of crap. > > David Of course you are, in part, right. GnuPG should be easier to set up and use. The GnuPG team is well aware of this and work to make GnuPG easier to use. But your claims as to the difficulty of moving keys are not true. Yesterday at a large organization, I explained to a cow-orker how to create and distribute keys. The meeting did not take two hours. We are now testing the sub-system, and so far, it seems to work, that is, it does the job of encryption and decryption. You claim that you cannot just copy over .gnupg from machine A to machine B and get a working set of keys on machine B. But I have done this successfully more than a few times. I do not have a page of instructions, but if you wish, I will meet with you and we can try to find and/or write such a page. I think there already exists such a page, published on the Net, and published in paper and ink book form, but I will not look for it now. oo--JS. From jays at panix.com Fri Nov 14 22:58:00 2014 From: jays at panix.com (Jay Sulzberger) Date: Fri, 14 Nov 2014 16:58:00 -0500 (EST) Subject: Why the software is crap In-Reply-To: <5465FF8B.4000508@gmail.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <5465FF8B.4000508@gmail.com> Message-ID: On Fri, 14 Nov 2014, NdK wrote: > Il 14/11/2014 13:24, david at gbenet.com ha scritto: > >> I have cooled. You can export your private key - you can export your public > key. You can >> import your private key you can import your public key. In 20 years I have > always had the >> same problem - the same error message and have each time created a new set > of keys. I have >> done this 4 times. > If all four times you did the same wrong thing, then it's obvious that > you got the same wrong result. > > Just to prove it's your error, I copied my .gnupg from one system > (str957-142) to another (str957-004), with the most basic method I ould > think of. I'm not an expert (probably I transferred more than what was > needed!), but as you can see I succeeded at the first try! > > diego at str957-142:~$ gpg --list-secret-keys > /home/diego/.gnupg/secring.gpg > ------------------------------------------------ > sec 2048R/F9B9D307 2014-11-14 > uid Diego > ssb 2048R/3A4AD1C0 2014-11-14 > > diego at str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed > .gnupg > diego at str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz > > ?? necessaria una passphrase per sbloccare la chiave segreta > dell'utente: "Diego " > 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 > > diego at str957-142:~$ ls GnuPG-backup.tar.gz* > GnuPG-backup.tar.gz GnuPG-backup.tar.gz.asc > diego at str957-142:~$ scp GnuPG-backup.tar.gz diego at str957-004:/home/diego > > Then on the other PC: > > diego at str957-004:~$ tar xvfz GnuPG-backup.tar.gz > .gnupg/ > .gnupg/gpg-agent-info > .gnupg/pubring.kbx > .gnupg/gpg.conf > .gnupg/private-keys-v1.d/ > .gnupg/reader_0.status > .gnupg/pubring.gpg~ > .gnupg/secring.gpg > .gnupg/scdaemon.conf > .gnupg/gpa.conf > .gnupg/trustdb.gpg > .gnupg/pubring.gpg > diego at str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz > > ?? necessaria una passphrase per sbloccare la chiave segreta > dell'utente: "Diego " > 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 > > diego at str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc > gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID > chiave F9B9D307 > gpg: Firma valida da "Diego " > >> I notice that no one on this list - for all the talk of "oh I've done it" > can offer no >> practical information has to HOW. No one. No one. No one knows how to do > this simple task. >> In all my 20 years I have never found out how. Perhaps things are different > under a Windows >> O/S but on Linux there is NO SOLUTION. > Done just now in Ubuntu. So there's an error on your side. > > BYtE, > Diego. Thank you, Diego! One failure of the culture of Usenet and many mailing lists is an unreasonable reluctance to publish exact specific code, in answer to a question about how to do something. Often an answer of this form is given: Ah, you just have to frobniculate the upper side parser, then reduce the dimension of the third homotopy group by killing all high pressure *reverse* constraints forced by the file which specifies the Lipschitz spectrum, at level 2. Then just restart the daemon. It may take a minute or two, if the network checks are fully enabled, but that is the only trouble I have ever had, doing it this way. Some vora114 administrators recommend re-compiling all of the Lipschitz spectrum, some even suggest regenerating the Sobolev softmax pragmata, but I have never found that necessary. which is correct, and easily understood by anyone who already knows how to do the task, but difficult to understand, if you do not already know how to do the task. A more useful answer is: Become root on the machine. Then do root at example:~# cd /etc/vora114 root at example:~# cp -a lipschitz.conf lipschitz.conf.bak root at example:~# echo frob upper 2 safe >> side-parse.conf root at example:~# echo :l2 v.. greater-than > l2.l.rev.remove root at example:~# grep -v -f l2.l.rev.remove lipschitz.conf > lipschitz.conf.temp root at example:~# mv lipschitz.conf.temp lipschitz.conf root at example:~# /etc/init.d/vora114 force-reload You may, if vora114 checks all network connections, have to wait a few minutes for vora114 to fully start. So wait five minutes and then do root at example:~# /etc/init.d/vora114 status and send us a copy of the first sixty lines of output. oo--JS. From alexanderino at gmail.com Fri Nov 14 23:00:46 2014 From: alexanderino at gmail.com (Jason Antony) Date: Sat, 15 Nov 2014 09:00:46 +1100 Subject: My Conclusions In-Reply-To: <54663827.4070206@gbenet.com> References: <5465DC99.3060803@gbenet.com> <5465EB6C.8070302@gbenet.com> <5465F259.2030106@gmail.com> <54663827.4070206@gbenet.com> Message-ID: <54667B8E.6040506@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-15 04:13, david at gbenet.com wrote: > Another pointless answer - no practical data - so there's no > validity in what you say You are squandering the goodwill of those trying to help you with such responses, of which you have sent many more. No one has an obligation to assist you, especially when their requests for terminal output are ignored, instead met with childish tantrums and hissy fits. If you want results, learn to behave in a mature manner. Be polite, and work with us. Else, feel free to leave the list. We do not need belligerent ingrates. Regards, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUZnuNAAoJED1Q2DsLuMaG6IEP/jVu/10yNH61YciCs8h8MbwG JXGDZMG6Ob9jCsYYLm1IknLtoC1aTV1l84Eo4KTo+8rzpifiucDaKgkbd3292Zpy SM8JPXJGF8yxgNOENAr7zsv8AfyecPE3ec2aboGNUF+dtMLnQHt2j+xNahwnfsXp HOVcv9GbQWzak6TToeeE5uTsKSCIRtGgRiSM2Bw38eyGruROzYXD8v6ud2VHV/u4 C9v9CsPwkULpLhfCtLB2rymK+R//WlzFocdx+2ckDES6e/6bn1MyvQHtv5jUZrYw gr5fmvULnbrcjdrm3XuGbhApHaATx1UbETTBNoJahQFdLW0OVBQwfoAsBtF76bZ0 2EUU0fGvtiClBFV9m03aaIccWNm6nC0lvYsaKFl5vp345rfhZ4tnKUP/Hb+NT2KC S4SE8S3uVyNky52GE7CsdA+jRIVfiLpWj4P9wWwNGkC9j5+cSb/IyOP+7e8zSvaO QZ97IB45AUMZX2mmS2ERYrdtt5vx60fhH8NTeiFUEBCJt7ZpkG37mCj3oSE/n91t Ukn7IJJrxZwgotemc70ju5+b0X2tTOBYAtnK44ESCafabpRHIO541V7oib4hV8ss laaCiU7WNw0P4CVSCoMBRePCh2qqH4BxrwiF3+Tp3dRgiR9JQuA0eSHKPufThQzD PiBjrcJDyLFOz9I8o5T1 =3TmU -----END PGP SIGNATURE----- From htd+ml at fritha.org Fri Nov 14 23:28:49 2014 From: htd+ml at fritha.org (Heinz Diehl) Date: Fri, 14 Nov 2014 23:28:49 +0100 Subject: Why the software is crap In-Reply-To: <54663772.4020704@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EBDB.5060701@gmail.com> <54663772.4020704@gbenet.com> Message-ID: <20141114222849.GA5203@fritha.org> ___________________________ /| /| | | ||__|| | Please don't | / O O\__ feed | / \ the troll | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________ From mick.crane at gmail.com Fri Nov 14 23:29:38 2014 From: mick.crane at gmail.com (Mick Crane) Date: Fri, 14 Nov 2014 22:29:38 +0000 Subject: Why the software is crap In-Reply-To: <54663AC5.50500@gbenet.com> References: <5465EA7A.2050005@gbenet.com> <5465EDBC.2000908@dkyb.de> <5465F47A.2000709@gbenet.com> <5465FF8B.4000508@gmail.com> <54663AC5.50500@gbenet.com> Message-ID: <0582A909-7B50-45BB-9EEB-643A6BA754C7@gmail.com> Something is strange, I don't know much about this stuff but it seems important to you to have encryption working. It is so easy these days to install an OS automagically I would, in your case, make a fresh installation on some other machine and do what it is you want to do to prove a point. Then once you see it working you have confidence. Cheers Mick -- Key ID: 0x4BFEBB31 > On 14 Nov 2014, at 17:24, "david at gbenet.com" wrote: > >> On 14/11/14 13:11, NdK wrote: >> Il 14/11/2014 13:24, david at gbenet.com ha scritto: >> >>> I have cooled. You can export your private key - you can export your public key. You can >>> import your private key you can import your public key. In 20 years I have always had the >>> same problem - the same error message and have each time created a new set of keys. I have >>> done this 4 times. >> If all four times you did the same wrong thing, then it's obvious that you got the same >> wrong result. >> >> Just to prove it's your error, I copied my .gnupg from one system (str957-142) to another >> (str957-004), with the most basic method I ould think of. I'm not an expert (probably I >> transferred more than what was needed!), but as you can see I succeeded at the first try! >> >> diego at str957-142:~$ gpg --list-secret-keys >> /home/diego/.gnupg/secring.gpg >> ------------------------------------------------ >> sec 2048R/F9B9D307 2014-11-14 >> uid Diego >> ssb 2048R/3A4AD1C0 2014-11-14 >> >> diego at str957-142:~$ tar cvfz GnuPG-backup.tar.gz --exclude random_seed .gnupg >> diego at str957-142:~$ gpg --clearsign GnuPG-backup.tar.gz >> >> ? necessaria una passphrase per sbloccare la chiave segreta >> dell'utente: "Diego " >> 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 >> >> diego at str957-142:~$ ls GnuPG-backup.tar.gz* >> GnuPG-backup.tar.gz GnuPG-backup.tar.gz.asc >> diego at str957-142:~$ scp GnuPG-backup.tar.gz diego at str957-004:/home/diego >> >> Then on the other PC: >> >> diego at str957-004:~$ tar xvfz GnuPG-backup.tar.gz >> .gnupg/ >> .gnupg/gpg-agent-info >> .gnupg/pubring.kbx >> .gnupg/gpg.conf >> .gnupg/private-keys-v1.d/ >> .gnupg/reader_0.status >> .gnupg/pubring.gpg~ >> .gnupg/secring.gpg >> .gnupg/scdaemon.conf >> .gnupg/gpa.conf >> .gnupg/trustdb.gpg >> .gnupg/pubring.gpg >> diego at str957-004:~$ gpg --clearsign GnuPG-backup.tar.gz >> >> ? necessaria una passphrase per sbloccare la chiave segreta >> dell'utente: "Diego " >> 2048-bit chiave RSA, ID F9B9D307, creata 2014-11-14 >> >> diego at str957-004:~$ gpg --verify GnuPG-backup.tar.gz.asc >> gpg: Firma eseguita in data ven 14 nov 2014 14:07:57 CET usando RSA, ID chiave F9B9D307 >> gpg: Firma valida da "Diego " >> >>> I notice that no one on this list - for all the talk of "oh I've done it" can offer no >>> practical information has to HOW. No one. No one. No one knows how to do this simple task. >>> In all my 20 years I have never found out how. Perhaps things are different under a Windows >>> O/S but on Linux there is NO SOLUTION. >> Done just now in Ubuntu. So there's an error on your side. >> >> BYtE, >> Diego. >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > I have a clean install of 64 bit LXD - all programmes are working 100 per cent. My keys get > imported perfectly - every programme including Enigmail knows they are there. But when I try > to sign or sign and encrypt I get the error referred too. No amount of copying no amount of > backups no amount of anything will change that fact. > > David > > > -- > ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No > delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From idmsdba at nycap.rr.com Sat Nov 15 00:11:14 2014 From: idmsdba at nycap.rr.com (Michael A. Yetto) Date: Fri, 14 Nov 2014 18:11:14 -0500 Subject: Why the software is crap In-Reply-To: <20141114222849.GA5203@fritha.org> References: <5465EA7A.2050005@gbenet.com> <5465EBDB.5060701@gmail.com> <54663772.4020704@gbenet.com> <20141114222849.GA5203@fritha.org> Message-ID: <20141114181114.065f3885@Braetac.lighthouse.yetnet> On Fri, 14 Nov 2014 23:28:49 +0100 Heinz Diehl wrote: > ___________________________ > /| /| | | > ||__|| | Please don't | > / O O\__ feed | > / \ the troll | > / \ \ | > / _ \ \ ---------------------- > / |\____\ \ || > / | | | |\____/ || > / \|_|_|/ | __|| > / / \ |____| || > / | | /| | --| > | | |// |____ --| > * _ | |_|_|_| | \-/ >*-- _--\ _ \ // | > / _ \\ _ // | / >* / \_ /- | - | | > * ___ c_c_c_C/ \C_c_c_c____________ > > It was starting to look like Usenet in here. On a group that I frequent we (TINW - There Is No We) had a nearly three year campaign by a troll end recently. His technique was to ask for help on multiple problems and then claim that the solutions offered didn't work on Linux, but weren't even needed on Windows. -- Mike "yes he did get abusive and insulting quickly" Yetto "That which can be destroyed by the truth, should be." - P. C. Hodgell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From tristan.santore at internexusconnect.net Sat Nov 15 02:36:47 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Sat, 15 Nov 2014 02:36:47 +0100 Subject: Why the software is crap In-Reply-To: <20141114181114.065f3885@Braetac.lighthouse.yetnet> References: <5465EA7A.2050005@gbenet.com> <5465EBDB.5060701@gmail.com> <54663772.4020704@gbenet.com> <20141114222849.GA5203@fritha.org> <20141114181114.065f3885@Braetac.lighthouse.yetnet> Message-ID: <5466AE2F.4050403@internexusconnect.net> On 15/11/14 00:11, Michael A. Yetto wrote: > On Fri, 14 Nov 2014 23:28:49 +0100 > Heinz Diehl wrote: > >> ___________________________ >> /| /| | | >> ||__|| | Please don't | >> / O O\__ feed | >> / \ the troll | >> / \ \ | >> / _ \ \ ---------------------- >> / |\____\ \ || >> / | | | |\____/ || >> / \|_|_|/ | __|| >> / / \ |____| || >> / | | /| | --| >> | | |// |____ --| >> * _ | |_|_|_| | \-/ >> *-- _--\ _ \ // | >> / _ \\ _ // | / >> * / \_ /- | - | | >> * ___ c_c_c_C/ \C_c_c_c____________ >> >> > > It was starting to look like Usenet in here. On a group that I > frequent we (TINW - There Is No We) had a nearly three year > campaign by a troll end recently. His technique was to ask for > help on multiple problems and then claim that the solutions > offered didn't work on Linux, but weren't even needed on Windows. > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > We call those people, time waster trolls in IRC land. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org From jhs at berklix.com Sat Nov 15 03:42:39 2014 From: jhs at berklix.com (Julian H. Stacey) Date: Sat, 15 Nov 2014 03:42:39 +0100 Subject: Why the software is crap In-Reply-To: Your message "Fri, 14 Nov 2014 23:28:49 +0100." <20141114222849.GA5203@fritha.org> Message-ID: <201411150242.sAF2gdHP009544@fire.js.berklix.net> Heinz Diehl wrote: > ||__|| | Please don't | > / O O\__ feed | > / \ the troll | Best forcibly un-subscribe . Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From david at gbenet.com Sat Nov 15 12:52:02 2014 From: david at gbenet.com (david at gbenet.com) Date: Sat, 15 Nov 2014 11:52:02 +0000 Subject: The Facts: Message-ID: <54673E62.6030506@gbenet.com> The steps I have taken to move my /.gnupg folder Background: I have two laptops (1) a 32 bit LXD laptop-1 (2) a 64 bit LXD laptop-2 one mouse and one WD 1.0 TB (1,000,202,043,392 bytes) external drive that plugs into the USB port of either laptop-1 or laptop-2 = david at laptop-1:/media/store$. Laptop-1 and laptop-2 are a mirror image of each. They contain the same software. I copied programmes like Thunderbird Firefox from laptop-1 to laptop-2 without any problems. gpg --version david at laptop-1:/media/store$ gpg --version gpg (GnuPG) 1.4.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cypher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12), CAMELLIA256 (S13) Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10), SHA224 (H11) Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3) david at laptop-1:/media/store$ david at laptop-1:/media/store$ gpg2 --version gpg (GnuPG) 2.0.17 libgcrypt 1.5.0 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cypher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12), CAMELLIA256 (S13) Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10), SHA224 (H11) Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3) david at laptop-1:/media/store$ I have GPA Kleopatra Seahorse and Kgpg on laptop-1 and laptop-2. They all make "calls" to gnupg. I at first made a copy of my public key I decided to use Kgpg to save my public key postmaster.asc which I saved to david at laptop-1:/media/store$. It is to be noted that both laptops are "laptop-1" So now All tasks are performed on the 64 bit LXD laptop: (1) david at laptop-1:~$ gpg gpg: directory `/home/david/.gnupg' created gpg: new configuration file `/home/david/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/david/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/home/david/.gnupg/secring.gpg' created gpg: keyring `/home/david/.gnupg/pubring.gpg' created gpg: Go ahead and type your message ... (2) Run ALL your GUIs eg Kgpg Kleopatra GPA - but do not create a new set of keys! Kgpg will complain and not run. (3) Reboot your system - very important! (4) Type david at laptop-1:~$ gpg-agent gpg-agent: gpg-agent running and available david at laptop-1:~$ (5) Then I discovered failings within Thunderbird/Enigmail - I did various test e-mails skipper at gbenet.com to postmaster at gbenet.com admin at bikermates.org to david at gbenet.com - all failed to support signing all failed to support encryption. (6) I tried doing backups - I tried deleting pubring - in fact I tried doing everything that was possible to do. Then I switched back to the 32 bit laptop today (15th 11th 2014 and decided to investigate the "problem." gpg --list-secret-keys david at laptop-1:/media/store$ gpg --list-secret-keys gpg: using PGP trust model /home/david/.gnupg/secring.gpg ------------------------------ sec 4096R/AAD8C47D 2014-08-17 uid postmaster (There's always light at the end of the tunnel) ssb 4096R/FDDA1EF2 2014-08-17 david at laptop-1:/media/store$ gpg --output mykey1.asc --export -a AAD8C47D gpg --output mykey2.asc --export -a FDDA1EF2 david at laptop-1:/media/store$ gpg --output mykey1.asc --export -a AAD8C47D gpg: writing to `mykey1.asc' gpg: can't handle public key algorithm 19 gpg: can't handle public key algorithm 18 david at laptop-1:/media/store$ gpg --output mykey2.asc --export -a FDDA1EF2 gpg: writing to `mykey2.asc' gpg: can't handle public key algorithm 19 gpg: can't handle public key algorithm 18 But apart from the can't handle public key algorithm 19 and gpg: can't handle public key algorithm 18 I got the two files. But I decided to use: gpg -ao david-private.key --export-secret-keys AAD8C47D david at laptop-1:/media/store$ gpg -ao david-private.key --export-secret-keys AAD8C47D gpg: writing to `david-private.key' david at laptop-1:/media/store$ gpg -ao allow-non-selfsigned-uid david-public.key --export FDDA1EF2 david at laptop-1:/media/store$ gpg -ao david-public.key --export FDDA1EF2 gpg: writing to `david-public.key' gpg: can't handle public key algorithm 19 gpg: can't handle public key algorithm 18 david at laptop-1:/media/store$ Got the same error message. there's something wrong with subkey binding signatures for secret keys. david at laptop-1:/media/store$ gpg --allow-non-selfsigned-uid -ao david-public.key --export FDDA1EF2 File `david-public.key' exists. Overwrite? (y/N) y gpg: writing to `david-public.key' gpg: can't handle public key algorithm 19 gpg: can't handle public key algorithm 18 david at laptop-1:/media/store$ So now am going to shut down "laptop-1" 32 bit LXD and boot up "laptop-1" 64 bit LXD and run: gpg --import --allow-non-selfsigned-uid -ao david-public.key in the hope this will fix the problem. I will post results. The results: david at laptop-1:/media/david/store$ gpg -ao --import --allow-non-selfsigned-uid david-public.key gpg: armour header: Version: GnuPG v1.4.11 (GNU/Linux) pub 4096R/AAD8C47D 2014-08-17 postmaster (There's always light at the end of the tunnel) sig AAD8C47D 2014-11-15 [selfsig] gpg: can't handle public key algorithm 19 gpg: can't handle public key algorithm 18 sig 32521C09 2014-08-25 Carolyn Hoyle (I respect privacy) sub 4096R/FDDA1EF2 2014-08-17 sig AAD8C47D 2014-08-17 [keybind] david at laptop-1:/media/david/store$ Now to test emails - the results: skipper at gbenet.com to postmaster at gbenet.com subject test body: test - now send: "Key 0xAAD8C47D not found or not valid. The (sub-)key might of expired." I'm stuck - can you solve this problem? David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From johannes at zarl.at Sat Nov 15 13:36:13 2014 From: johannes at zarl.at (Johannes Zarl) Date: Sat, 15 Nov 2014 13:36:13 +0100 Subject: The Facts: In-Reply-To: <54673E62.6030506@gbenet.com> References: <54673E62.6030506@gbenet.com> Message-ID: <1551016.vMv5Bgozjo@mani> Hi, On Saturday 15 November 2014 11:52:02 david at gbenet.com wrote: > Laptop-1 and laptop-2 are a mirror image of each. They contain the same > software. I copied programmes like Thunderbird Firefox from laptop-1 to > laptop-2 without any problems. It seems like the mirroring of laptop-1 to laptop-2 did not actually work as expected: > (1) david at laptop-1:~$ gpg > gpg: directory `/home/david/.gnupg' created > gpg: new configuration file `/home/david/.gnupg/gpg.conf' created > gpg: WARNING: options in `/home/david/.gnupg/gpg.conf' are not yet active > during this run gpg: keyring `/home/david/.gnupg/secring.gpg' created > gpg: keyring `/home/david/.gnupg/pubring.gpg' created > gpg: Go ahead and type your message ... The above command output tells you that no .gnupg folder exists in your home directory and that a new one is created. As some people pointed out before, you have to copy the .gnupg folder from your laptop-1 to your laptop-2. Maybe you forgot to restore your home directory when you migrated from laptop-1 to laptop-2? Cheers, Johannes From david at gbenet.com Sat Nov 15 15:30:10 2014 From: david at gbenet.com (david at gbenet.com) Date: Sat, 15 Nov 2014 14:30:10 +0000 Subject: The Facts: In-Reply-To: <1551016.vMv5Bgozjo@mani> References: <54673E62.6030506@gbenet.com> <1551016.vMv5Bgozjo@mani> Message-ID: <54676372.4010407@gbenet.com> On 15/11/14 12:36, Johannes Zarl wrote: > Hi, > > On Saturday 15 November 2014 11:52:02 david at gbenet.com wrote: >> Laptop-1 and laptop-2 are a mirror image of each. They contain the same >> software. I copied programmes like Thunderbird Firefox from laptop-1 to >> laptop-2 without any problems. > > It seems like the mirroring of laptop-1 to laptop-2 did not actually work as > expected: > >> (1) david at laptop-1:~$ gpg >> gpg: directory `/home/david/.gnupg' created >> gpg: new configuration file `/home/david/.gnupg/gpg.conf' created >> gpg: WARNING: options in `/home/david/.gnupg/gpg.conf' are not yet active >> during this run gpg: keyring `/home/david/.gnupg/secring.gpg' created >> gpg: keyring `/home/david/.gnupg/pubring.gpg' created >> gpg: Go ahead and type your message ... > > The above command output tells you that no .gnupg folder exists in your home > directory and that a new one is created. As some people pointed out before, > you have to copy the .gnupg folder from your laptop-1 to your laptop-2. > > Maybe you forgot to restore your home directory when you migrated from > laptop-1 to laptop-2? > > Cheers, > Johannes > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > The nature of Linux is that your "home directory" is automatically created so one can hardly forget to create it. As stated laptop-1 has a 32 bit O/S and laptop-2 as a 64 bit O/S this means installing an 64 bit Linux Operating System and copying ALL programmes that are on the 32 bit Linux Operating System. They have the same programmes. This means that are a "mirror" of each - except that one is 32 bit and one 64 bit. No migration of an Linux operating system took place - it would be meaningless to put a 32 bit O/S on a laptop with more than 4 MB RAM as it would not recognise the additional memory. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 15 16:17:34 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 15 Nov 2014 15:17:34 +0000 Subject: Help needed In-Reply-To: <546531BB.2000206@gbenet.com> References: <546531BB.2000206@gbenet.com> Message-ID: <1804888045.20141115151734@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 13 November 2014 at 10:33:31 PM, in , david at gbenet.com wrote: > I exported my keys to a USB stick. Then I copied my > .gnupg to a new Linux laptop. Then I imported my keys. > I thought that I would be fine. > But I get the following error when signing my mail: > "Key 0xAAd8C47D not found or not valid. The (sub-)key > might have expired." Assuming you exported/imported the private keys as well as the public keys, did you set the ownertrust back to "ultimate" after importing? > The key is visible in Enigmail > Kgpg Kleopatra GPA I'm not able to edit my key I can't > enter my passphrase. For what it's worth, you don't need the passphrase to edit the ownertrust. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Ultimate consistency lies in being consistently inconsistent -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRnbqBXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p6LUD/Al1wZiVhTOL1JTL4ayx3Ab3djQOCtydbtL8 QZAQiKgGmcIbMxgIU92xv6u2pTVP3BueXwgDdQeVxuqo9/1i43WXS29imHam6FFt BkhCbo1r1z1/hbyVXUwFtiTJCiBb3q2ASH/4z7hvjvCfNM/ob1yqGeH3SCj24N6F wlf0Hs57 =gg/b -----END PGP SIGNATURE----- From david at gbenet.com Sat Nov 15 17:06:36 2014 From: david at gbenet.com (david at gbenet.com) Date: Sat, 15 Nov 2014 16:06:36 +0000 Subject: Help needed In-Reply-To: <1804888045.20141115151734@my_localhost> References: <546531BB.2000206@gbenet.com> <1804888045.20141115151734@my_localhost> Message-ID: <54677A0C.502@gbenet.com> On 15/11/14 15:17, MFPA wrote: > Hi > > > On Thursday 13 November 2014 at 10:33:31 PM, in > , david at gbenet.com wrote: > > >> I exported my keys to a USB stick. Then I copied my >> .gnupg to a new Linux laptop. Then I imported my keys. >> I thought that I would be fine. > >> But I get the following error when signing my mail: >> "Key 0xAAd8C47D not found or not valid. The (sub-)key >> might have expired." > > Assuming you exported/imported the private keys as well as the public > keys, did you set the ownertrust back to "ultimate" after importing? Yes > > > >> The key is visible in Enigmail >> Kgpg Kleopatra GPA I'm not able to edit my key I can't >> enter my passphrase. > > For what it's worth, you don't need the passphrase to edit the > ownertrust. > > > > -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From tfmnk at tfwno.gf Sat Nov 15 16:22:58 2014 From: tfmnk at tfwno.gf (Clarence) Date: Sat, 15 Nov 2014 23:22:58 +0800 Subject: How do I show the public keys? Message-ID: <54676FD2.6030601@tfwno.gf> GPG generated a key and copied to /.gnupg/trustdb.gpg: trustdb created but how do I show generated keys to other people? From philip.jackson at nordnet.fr Sat Nov 15 17:43:00 2014 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sat, 15 Nov 2014 17:43:00 +0100 Subject: Why the software is crap In-Reply-To: <201411150242.sAF2gdHP009544@fire.js.berklix.net> References: <201411150242.sAF2gdHP009544@fire.js.berklix.net> Message-ID: <54678294.9030903@nordnet.fr> On 15/11/14 03:42, Julian H. Stacey wrote: > Heinz Diehl wrote: >> ||__|| | Please don't | >> / O O\__ feed | >> / \ the troll | > > Best forcibly un-subscribe . > > Cheers, > Julian > It appears that David might well be the postmaster at gbenet.com which seems to be a recent site apparently specializing in cryptology. What little it contains has to be accessed via the 'sitemap'. The texts are a similar sort of rant, in poor language with little if any punctuation. The name of the site recalls to me what was a popular expletive in the UK in or around the 1970's : "Gordon Bennett!!" Best forgotten. Philip From samir at samirnassar.com Sat Nov 15 17:47:37 2014 From: samir at samirnassar.com (Samir Nassar) Date: Sat, 15 Nov 2014 17:47:37 +0100 Subject: How do I show the public keys? In-Reply-To: <54676FD2.6030601@tfwno.gf> References: <54676FD2.6030601@tfwno.gf> Message-ID: <3571256.gcqKSDaRP6@forge> On Saturday, 2014-11-15 23:22:58 Clarence wrote: > GPG generated a key and copied to /.gnupg/trustdb.gpg: trustdb created > > but how do I show generated keys to other people? From the terminal you can run: $gpg -K --fingerprint For me this shows: /home/snassar/.gnupg/secring.gpg -------------------------------- sec 4096R/0xFE679A908E997AB2 2013-02-24 [expires: 2015-02-14] Key fingerprint = EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 uid Samir Nassar uid Samir Nassar uid Samir Nassar ssb 4096R/0x0843DE6EE49FE725 2013-02-24 Key fingerprint = F081 A878 44D1 C6F7 E5EA 7C22 0843 DE6E E49F E725 ssb 4096R/0x8C1C1114D3DF46EA 2013-02-24 Key fingerprint = 4593 BB95 5BB7 E73F 6B04 04E7 8C1C 1114 D3DF 46EA ssb 4096R/0x8448DA08EB5A611A 2013-02-24 Key fingerprint = 3D3E 90F8 5633 F512 8D6C 4D20 8448 DA08 EB5A 611A -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From patrick at enigmail.net Sat Nov 15 18:00:55 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sat, 15 Nov 2014 18:00:55 +0100 Subject: The Facts: In-Reply-To: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> Message-ID: <546786C7.5030702@enigmail.net> On 15.11.14 12:52, david at gbenet.com wrote: > The steps I have taken to move my /.gnupg folder > > Background: > > I have two laptops (1) a 32 bit LXD laptop-1 (2) a 64 bit LXD > laptop-2 one mouse and one WD 1.0 TB (1,000,202,043,392 bytes) > external drive that plugs into the USB port of either laptop-1 or > laptop-2 = david at laptop-1:/media/store$. > > Laptop-1 and laptop-2 are a mirror image of each. They contain the > same software. I copied programmes like Thunderbird Firefox from > laptop-1 to laptop-2 without any problems. Why don't you simply do this: 1. on your old laptop: tar zcf gnupg-backup.tgz $HOME/.gnupg 2. Copy the resulting file "gnupg-backup.tgz" to your new laptop 3. on your new laptop: tar zxf gnupg-backup.tgz -Patrick From tfmnk at tfwno.gf Sat Nov 15 18:12:24 2014 From: tfmnk at tfwno.gf (tfmnk) Date: Sun, 16 Nov 2014 01:12:24 +0800 Subject: How do I show the public keys? Message-ID: GnuPG shows public keys in that way? Samir Nassar wrote: >On Saturday, 2014-11-15 23:22:58 Clarence wrote: >> GPG generated a key and copied to /.gnupg/trustdb.gpg: trustdb created >> >> but how do I show generated keys to other people? > >From the terminal you can run: > >$gpg -K --fingerprint > >For me this shows: > >/home/snassar/.gnupg/secring.gpg >-------------------------------- >sec 4096R/0xFE679A908E997AB2 2013-02-24 [expires: 2015-02-14] > Key fingerprint = EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 >uid Samir Nassar >uid Samir Nassar >uid Samir Nassar >ssb 4096R/0x0843DE6EE49FE725 2013-02-24 > Key fingerprint = F081 A878 44D1 C6F7 E5EA 7C22 0843 DE6E E49F E725 >ssb 4096R/0x8C1C1114D3DF46EA 2013-02-24 > Key fingerprint = 4593 BB95 5BB7 E73F 6B04 04E7 8C1C 1114 D3DF 46EA >ssb 4096R/0x8448DA08EB5A611A 2013-02-24 > Key fingerprint = 3D3E 90F8 5633 F512 8D6C 4D20 8448 DA08 EB5A 611A > >-- >Samir Nassar >samir at samirnassar.com >https://samirnassar.com >PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 >_______________________________________________ >Gnupg-users mailing list >Gnupg-users at gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-users From david at gbenet.com Sat Nov 15 18:16:43 2014 From: david at gbenet.com (david at gbenet.com) Date: Sat, 15 Nov 2014 17:16:43 +0000 Subject: The Facts: In-Reply-To: <546786C7.5030702@enigmail.net> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> Message-ID: <54678A7B.8050400@gbenet.com> On 15/11/14 17:00, Patrick Brunschwig wrote: > On 15.11.14 12:52, david at gbenet.com wrote: >> The steps I have taken to move my /.gnupg folder >> >> Background: >> >> I have two laptops (1) a 32 bit LXD laptop-1 (2) a 64 bit LXD >> laptop-2 one mouse and one WD 1.0 TB (1,000,202,043,392 bytes) >> external drive that plugs into the USB port of either laptop-1 or >> laptop-2 = david at laptop-1:/media/store$. >> >> Laptop-1 and laptop-2 are a mirror image of each. They contain the >> same software. I copied programmes like Thunderbird Firefox from >> laptop-1 to laptop-2 without any problems. > > Why don't you simply do this: > > 1. on your old laptop: > > tar zcf gnupg-backup.tgz $HOME/.gnupg > > > 2. Copy the resulting file "gnupg-backup.tgz" to your new laptop > > > 3. on your new laptop: > > tar zxf gnupg-backup.tgz > > > -Patrick > Patric, I did that. But now I have half resolved the issue. The error only appears on a 64 bit gpg2 system - I removed all refs in Enigmail to gpg2 - now the only error message I get is "bad passphrase." I recall having a 64 bit Fedora O/S and experiencing the same kind of problems about 4 years ago. Now my only problem is I can not change the passphrase GPA Kleopatra KGpg or from the terminal. So am going to un-install gpg2 - I hope that fixes the problems. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From david at gbenet.com Sat Nov 15 18:19:29 2014 From: david at gbenet.com (david at gbenet.com) Date: Sat, 15 Nov 2014 17:19:29 +0000 Subject: The Facts: In-Reply-To: <53838437-B274-4419-B176-744FEA4E2AB3@gmail.com> References: <54673E62.6030506@gbenet.com> <53838437-B274-4419-B176-744FEA4E2AB3@gmail.com> Message-ID: <54678B21.8090802@gbenet.com> On 15/11/14 17:16, Paul R. Ramer wrote: > On November 15, 2014 3:52:02 AM PST, "david at gbenet.com" wrote: > [snip] >> david at laptop-1:/media/david/store$ gpg -ao --import >> --allow-non-selfsigned-uid david-public.key >> gpg: armour header: Version: GnuPG v1.4.11 (GNU/Linux) >> pub 4096R/AAD8C47D 2014-08-17 postmaster (There's always light at the >> end of the tunnel) >> >> sig AAD8C47D 2014-11-15 [selfsig] >> gpg: can't handle public key algorithm 19 >> gpg: can't handle public key algorithm 18 >> sig 32521C09 2014-08-25 Carolyn Hoyle (I respect privacy) >> >> sub 4096R/FDDA1EF2 2014-08-17 >> sig AAD8C47D 2014-08-17 [keybind] >> david at laptop-1:/media/david/store$ >> >> Now to test emails - the results: >> >> skipper at gbenet.com to postmaster at gbenet.com subject test body: test - >> now send: >> >> "Key 0xAAD8C47D not found or not valid. The (sub-)key might of >> expired." >> >> I'm stuck - can you solve this problem? > > David, > > If this is the entirety of what you did, you forgot to import your private key in the file david-private.gpg. > > Cheers, > > -Paul > > -- > PGP: 3DB6D884 > I've installed my private key - am not that stupid! Anyway things have moved on - it's a gpg2 problem David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From samir at samirnassar.com Sat Nov 15 18:40:54 2014 From: samir at samirnassar.com (Samir Nassar) Date: Sat, 15 Nov 2014 18:40:54 +0100 Subject: How do I show the public keys? In-Reply-To: References: Message-ID: <2303149.KTACVaPf8i@forge> On Sunday, 2014-11-16 01:12:24 tfmnk wrote: > GnuPG shows public keys in that way? Bah. My mistake. I read public key, but acted for fingerprint. You can choose to use an ID, the fingerprint, or a key ID. For reference though, use the fine GnuPG manual entry here: https://www.gnupg.org/gph/en/manual.html#AEN65 By Key ID: $gpg --export --armor 0xFE679A908E997AB2 By ID: $gpg --export --armor samir at samirnassar.com By fingerprint: $gpg --export --armor EE76B39E07788F95F796B044FE679A908E997AB2 Samir -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From david at gbenet.com Sat Nov 15 18:53:57 2014 From: david at gbenet.com (david at gbenet.com) Date: Sat, 15 Nov 2014 17:53:57 +0000 Subject: Nearly fixed Message-ID: <54679335.1030100@gbenet.com> Hi All, The problem is with gpg2 on a 64 bit O/S I removed gpg2 and also lost GPA and Kleopatra and Kgpg no longer runs on my 64 bit Linux. Now my only error is "bad passphrase." Which I can not change from the terminal. Also as I recall the problem is with Enigmail - I have to install a version of Thunderbird at least 3 years older than my current version with an enigmail current to that version. This will get rid of all errors. Hopefully :) A rule maybe - "don't run gpg2 on a 64 bit Linux system - and install a much older version of Thunderbird and enigmail - and never upgrade Thunderbird to a newer version." David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com From samir at samirnassar.com Sat Nov 15 19:02:44 2014 From: samir at samirnassar.com (Samir Nassar) Date: Sat, 15 Nov 2014 19:02:44 +0100 Subject: Nearly fixed In-Reply-To: <54679335.1030100@gbenet.com> References: <54679335.1030100@gbenet.com> Message-ID: <1993197.P7LUBvh86f@forge> On Saturday, 2014-11-15 17:53:57 david at gbenet.com wrote: > A rule maybe - "don't run gpg2 on a 64 bit Linux system - and install a much > older version of Thunderbird and enigmail - and never upgrade Thunderbird > to a newer version." For those of you who come to David's post in the future through the mailing list archive: Disregard this misconception. Many of us, myself included, use gpg2 on a 64bit system without a problem. Samir -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From johanw at vulcan.xs4all.nl Sat Nov 15 19:10:25 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 15 Nov 2014 19:10:25 +0100 Subject: The Facts: In-Reply-To: <54678A7B.8050400@gbenet.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> Message-ID: <54679711.9060305@vulcan.xs4all.nl> On 15-11-2014 18:16, david at gbenet.com wrote: > I did that. But now I have half resolved the issue. The error only appears on a 64 bit gpg2 > system I believe there exist some differences between gpg2 keyrings and gpg 1.x keyrings, but I don't know the details. Does gpg2 still use trustdb.gpg? And since gpg 2.1 dropped v3 key support, how does it react on a keyring with v3 keys in it? Since I don't use gpg2 myself I can't test it right now. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From free10pro at gmail.com Sat Nov 15 18:16:26 2014 From: free10pro at gmail.com (Paul R. Ramer) Date: Sat, 15 Nov 2014 09:16:26 -0800 Subject: The Facts: In-Reply-To: <54673E62.6030506@gbenet.com> References: <54673E62.6030506@gbenet.com> Message-ID: <53838437-B274-4419-B176-744FEA4E2AB3@gmail.com> On November 15, 2014 3:52:02 AM PST, "david at gbenet.com" wrote: [snip] >david at laptop-1:/media/david/store$ gpg -ao --import >--allow-non-selfsigned-uid david-public.key >gpg: armour header: Version: GnuPG v1.4.11 (GNU/Linux) >pub 4096R/AAD8C47D 2014-08-17 postmaster (There's always light at the >end of the tunnel) > >sig AAD8C47D 2014-11-15 [selfsig] >gpg: can't handle public key algorithm 19 >gpg: can't handle public key algorithm 18 >sig 32521C09 2014-08-25 Carolyn Hoyle (I respect privacy) > >sub 4096R/FDDA1EF2 2014-08-17 >sig AAD8C47D 2014-08-17 [keybind] >david at laptop-1:/media/david/store$ > >Now to test emails - the results: > >skipper at gbenet.com to postmaster at gbenet.com subject test body: test - >now send: > >"Key 0xAAD8C47D not found or not valid. The (sub-)key might of >expired." > >I'm stuck - can you solve this problem? David, If this is the entirety of what you did, you forgot to import your private key in the file david-private.gpg. Cheers, -Paul -- PGP: 3DB6D884 From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 15 20:45:27 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 15 Nov 2014 19:45:27 +0000 Subject: Error message "Ohhhh jeeee: ... this is a bug" Message-ID: <629851038.20141115194527@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi I just got the following error messages from Gnupg 2.1 and Windows XP:- gpg: Ohhhh jeeee: ... this is a bug (/home/wk/b-w32/speedo/gnupg- 2.1.0/g10/import.c:1278:transfer_secret_keys) This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. The command I had run, which had been chundering away for a couple of minutes, was:- gpg --no-options --no-default-keyring --import "C:\Documents and Settings\Administrator\Application Data\GnuPG\secring.gpg" I have tried the command again and got the same error message. Then I ran it again with --debug-all; I can forward the output but will not post itin the clear to the list. (For context, I was trying to import all keys/keyrings I have around, to see if it would stop me getting "gpg: Oops: keyid_from_fingerprint: no pubkey" for --list-keys and --list-secret-keys operations.) - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Great minds discuss ideas; Average minds discuss events; Small minds discuss people. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRnrVxXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p5LoD/1LhxDv8HZV/8EgTY8j4vldEDBb+0JRvjoyQ jRhyWriaFihLD+BIFz1R3k4pMt5M408EbJ4qpuleGHYme174I+T2guklWq7vRafB NLxlgwEbC0hxs2pihTvNLYZK7OEvMWJizLdIbsXL9gf+EjA484ZgITUumRSeSsYM q/RX6+rZ =37QX -----END PGP SIGNATURE----- From wk at gnupg.org Sat Nov 15 21:16:18 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Nov 2014 21:16:18 +0100 Subject: Nearly fixed In-Reply-To: <1993197.P7LUBvh86f@forge> (Samir Nassar's message of "Sat, 15 Nov 2014 19:02:44 +0100") References: <54679335.1030100@gbenet.com> <1993197.P7LUBvh86f@forge> Message-ID: <87389kte25.fsf@vigenere.g10code.de> On Sat, 15 Nov 2014 19:02, samir at samirnassar.com said: > For those of you who come to David's post in the future through the mailing > list archive: Disregard this misconception. Many of us, myself included, use > gpg2 on a 64bit system without a problem. Actually I do the development on 64 bit and I also copy ~/.gnupg between 32 and 64 bit machines. On Windows GnuPG is a 32 bit application, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Nov 15 21:24:19 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 15 Nov 2014 21:24:19 +0100 Subject: The Facts: In-Reply-To: <54679711.9060305@vulcan.xs4all.nl> (Johan Wevers's message of "Sat, 15 Nov 2014 19:10:25 +0100") References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> Message-ID: <87sihkrz4c.fsf@vigenere.g10code.de> On Sat, 15 Nov 2014 19:10, johanw at vulcan.xs4all.nl said: > I believe there exist some differences between gpg2 keyrings and gpg 1.x > keyrings, but I don't know the details. Does gpg2 still use trustdb.gpg? No. Only with 2.1 tehre is the new keybox format (pubring.kbx) which will be used for new installations but an existing pubring.gpg from pre 2.1 will be used if it exists. > And since gpg 2.1 dropped v3 key support, how does it react on a keyring > with v3 keys in it? At the next write access to the keyring v3 keys are removed. David send me one of his mails privately without mentioning that he also send he to the ML :-(. I looked at it anyway; see below. Salam-Shalom, Werner On Sat, 15 Nov 2014 12:58, david at gbenet.com said: > sec 4096R/AAD8C47D 2014-08-17 > uid postmaster (There's always light at the end of the tunnel) > > ssb 4096R/FDDA1EF2 2014-08-17 > > david at laptop-1:/media/store$ > > gpg --output mykey1.asc --export -a AAD8C47D > gpg --output mykey2.asc --export -a FDDA1EF2 You are about to export the same key iwtice. Unless special options are used the --export command exports the main key "sec" and all subkeys "ssb". Not a problem but may be surprising. > gpg: can't handle public key algorithm 19 > gpg: can't handle public key algorithm 18 You played with the new ECC algorithms but not a problem. > david at laptop-1:/media/store$ > > gpg -ao allow-non-selfsigned-uid david-public.key --export FDDA1EF2 You wrote output to the file "allow-non-selfsigned-uid" ;-) > gpg: writing to `david-public.key' > gpg: can't handle public key algorithm 19 > gpg: can't handle public key algorithm 18 > david at laptop-1:/media/store$ > > Got the same error message. there's something wrong with subkey binding signatures for > secret keys. I can't see an error message. "can't handle public..." are just warnings about some othe keys found in the keyring or your key? > david at laptop-1:/media/david/store$ gpg -ao --import --allow-non-selfsigned-uid david-public.key > gpg: armour header: Version: GnuPG v1.4.11 (GNU/Linux) > pub 4096R/AAD8C47D 2014-08-17 postmaster (There's always light at the end of the tunnel) > > sig AAD8C47D 2014-11-15 [selfsig] > gpg: can't handle public key algorithm 19 > gpg: can't handle public key algorithm 18 > sig 32521C09 2014-08-25 Carolyn Hoyle (I respect privacy) > sub 4096R/FDDA1EF2 2014-08-17 > sig AAD8C47D 2014-08-17 [keybind] > david at laptop-1:/media/david/store$ It seems that you have ECC subkeys on your key or signed a key woth an ECC key. I can't check that because the keyservers do not yet all support ECC. > "Key 0xAAD8C47D not found or not valid. The (sub-)key might of expired." Please send me your complete key. The copy from the keyservers might not be complete. --export is sufficient. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mick.crane at gmail.com Sat Nov 15 22:14:43 2014 From: mick.crane at gmail.com (michael crane) Date: Sat, 15 Nov 2014 21:14:43 +0000 Subject: Nearly fixed In-Reply-To: <54679335.1030100@gbenet.com> References: <54679335.1030100@gbenet.com> Message-ID: I remember something like this happening with shorewall or smoothwall or something where this guy tried to get ownership of the opensource so then everybody jumped ship and made ipcop. Some guy came on the new mailing list and you would swear he was a wind-up, knew enough to keep you on your toes but retarded in composition, no idea if real or not. From rjh at sixdemonbag.org Sun Nov 16 03:28:39 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 15 Nov 2014 21:28:39 -0500 Subject: GnuPG Migration Assistant Message-ID: <54680BD7.3060508@sixdemonbag.org> Over the last few days there's been a lot of angry and hurtful words thrown about surrounding the subject of trying to migrate a GnuPG 2.0 keyring. I'm not going to weigh in on who's got the right of things or who's being unreasonable. I think we've all had the experience of being deeply frustrated with things not working the way we think they should, and as always I think a little sympathy for the frustrated is appropriate. Don't get angry. Do something productive instead. So, in a spare hour I put together a quick and dirty tool to help Mac OS X, Windows and UNIX users migrate their keyrings. It's such a quick and dirty tool that I don't have a fancy name for it, just "gpgma". If you want to take a look at it, download it from http://sixdemonbag.org/gpgma-0.1.zip. I've tested this out on both Windows 7 and on Fedora 20 using Mono 3.10. It's primitive but it works and it might help you. If there's interest from the list, I'll see about turning it into a real application. How does it work? 1. Uncompress the zipfile to a directory and cd into it. 2. (Windows) Double-click "gpgma.exe" (UNIX/Mac OS X) From a terminal, "mono ./gpgma.exe" 3. You'll have a bouncing baby zipfile on your desktop. FAQ: Q0. Didn't Hauke suggest something like this? A0. About a month ago or more, yes. Nothing came of it, so I decided to run with it. Q1. I don't trust it! I don't trust you! A1. Great! That's why you have source code. Q2. What's it licensed under? A2. This is so simple that I haven't even bothered to put an ISC license at the top. If it becomes important to you to have an official free license for it, I'll post a revision with the ISC license at the top. Q3. Why C#? A3. Because it works across Mac OS X, Windows, and the free UNIX community. Q4. How does it work? A4. As simply as possible. It figures out what OS it's running on and looks for the appropriate GnuPG data directory (%APPDATA%\GnuPG on Windows, $HOME/.gnupg for the others). It then walks through that directory looking for certain files, which it adds to a zipfile it writes to your desktop. (And yes, it handles the various Mac OS X, Windows and UNIX desktop directories correctly.) Q5. Where can I find a signature for it? I don't want to run a binary without having a signature. A5. The binary is signed with the Authenticode key I use for my professional work. There is no detached signature for the binary. Q6. What about a signature for the source code? A6. Why? It's like 100 lines. Read it yourself and figure out if there are any problems with it. Q7. It doesn't run on my [insert type of OS]. A7. You need either Microsoft's .NET runtime (4.0 or later), or Mono 3.2 or later. A lot of Linux distros still ship with Mono 2.10. Q8. It would be nice if... A8. I'm listening. Talk to me. Q9. Are you going to put this on Github? A9. At only 100 lines of code, it's kind of embarrassingly small to put on Github. If there's interest, though, I'll put it up. Q10. Is this an official GNU project? A10. No. Q11. Is this connected with GnuPG in any way? A11. No. Q12. I have Mono 3.10 on UNIX/Mac OS X. How do I compile it? A13. mcs -pkg:dotnet -r:System.IO.Compression -o:gpgma.exe gpgma.cs From 2014-667rhzu3dc-lists-groups at riseup.net Sun Nov 16 03:38:38 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 16 Nov 2014 02:38:38 +0000 Subject: Fermi estimates In-Reply-To: <54661967.30201@nordnet.fr> References: <546565B5.3040107@sixdemonbag.org> <54656AB2.2070802@sixdemonbag.org> <54661967.30201@nordnet.fr> Message-ID: <629327921.20141116023838@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 14 November 2014 at 3:01:59 PM, in , Philip Jackson wrote: > Does > he have to pause between each iteration to see if he > has 'something good' ? Could, presumably, stop after "several" iterations to check the last "several" results. Means extra potential iterations and fewer stops. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net It's better to feed one cat than many mice -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRoDjdXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pUugD/1zsjGlIE3XOgrTLSNSmuhDRslJzCm/az+zq rv8BC/w+XTllmlLtUV98yaXn18DhbyQg7KVfulam9qL/Unj1x4QpFi6mGe+tmc2f IZx92QL/NxzsmcGk52xhBbYB96F134nvOasnwrgenPb//rQUP2frTn07qq8W2iJu eaAGNJQoiQF8BAEBCgBmBQJUaA43XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwXbkH/1HMq9Y/bkYnYro8 IKhpKh4ogisRafwRCxO5FPVnP9l/o+cu0AR2y1yn1YXT21QhjovEo3HZBcuHG87H m9dEAPyWT7K2qBoSfDdFaA6/HqFOq5oX/cpbAtzPjTc/gzeAzDRB1B/puEsG6Hg5 PtemIObg4jHsni4UakxuKYlG683BogOa8shpO2pC1uRMpsXHHK+7L+zQntfMhS4f XFjacGapZEWY4E9RX60WYMbzghmpvJwI5beryNRT0zdHO/gHg5kW23UYrCowSv9t k1WVIZTdYl26W1qfaGG400Pynyp0kIXG+zaF3dxDAK2z4uxQDdJ6sbmm23tzT3EN G8EblZA= =Adv6 -----END PGP SIGNATURE----- From david at gbenet.com Sun Nov 16 05:59:16 2014 From: david at gbenet.com (david at gbenet.com) Date: Sun, 16 Nov 2014 04:59:16 +0000 Subject: The Facts: In-Reply-To: <87sihkrz4c.fsf@vigenere.g10code.de> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> Message-ID: <54682F24.6060709@gbenet.com> On 15/11/14 20:24, Werner Koch wrote: > On Sat, 15 Nov 2014 19:10, johanw at vulcan.xs4all.nl said: > >> I believe there exist some differences between gpg2 keyrings and gpg 1.x >> keyrings, but I don't know the details. Does gpg2 still use trustdb.gpg? > > No. Only with 2.1 tehre is the new keybox format (pubring.kbx) which > will be used for new installations but an existing pubring.gpg from pre > 2.1 will be used if it exists. > >> And since gpg 2.1 dropped v3 key support, how does it react on a keyring >> with v3 keys in it? > > At the next write access to the keyring v3 keys are removed. > > David send me one of his mails privately without mentioning that he also > send he to the ML :-(. I looked at it anyway; see below. > > > Salam-Shalom, > > Werner > > > On Sat, 15 Nov 2014 12:58, david at gbenet.com said: > >> sec 4096R/AAD8C47D 2014-08-17 >> uid postmaster (There's always light at the end of the tunnel) >> >> ssb 4096R/FDDA1EF2 2014-08-17 >> >> david at laptop-1:/media/store$ >> >> gpg --output mykey1.asc --export -a AAD8C47D >> gpg --output mykey2.asc --export -a FDDA1EF2 > > You are about to export the same key iwtice. Unless special options are > used the --export command exports the main key "sec" and all subkeys > "ssb". Not a problem but may be surprising. > >> gpg: can't handle public key algorithm 19 >> gpg: can't handle public key algorithm 18 > > You played with the new ECC algorithms but not a problem. > > >> david at laptop-1:/media/store$ >> >> gpg -ao allow-non-selfsigned-uid david-public.key --export FDDA1EF2 > > You wrote output to the file "allow-non-selfsigned-uid" ;-) > > >> gpg: writing to `david-public.key' >> gpg: can't handle public key algorithm 19 >> gpg: can't handle public key algorithm 18 >> david at laptop-1:/media/store$ >> >> Got the same error message. there's something wrong with subkey binding signatures for >> secret keys. > > I can't see an error message. "can't handle public..." are just warnings > about some othe keys found in the keyring or your key? > >> david at laptop-1:/media/david/store$ gpg -ao --import --allow-non-selfsigned-uid david-public.key >> gpg: armour header: Version: GnuPG v1.4.11 (GNU/Linux) >> pub 4096R/AAD8C47D 2014-08-17 postmaster (There's always light at the end of the tunnel) >> >> sig AAD8C47D 2014-11-15 [selfsig] >> gpg: can't handle public key algorithm 19 >> gpg: can't handle public key algorithm 18 >> sig 32521C09 2014-08-25 Carolyn Hoyle (I respect privacy) >> sub 4096R/FDDA1EF2 2014-08-17 >> sig AAD8C47D 2014-08-17 [keybind] >> david at laptop-1:/media/david/store$ > > > It seems that you have ECC subkeys on your key or signed a key woth an > ECC key. I can't check that because the keyservers do not yet all > support ECC. > >> "Key 0xAAD8C47D not found or not valid. The (sub-)key might of expired." > > Please send me your complete key. The copy from the keyservers might > not be complete. --export is sufficient. > > > Salam-Shalom, > > Werner > > > > Werner, I have partly resolved the problem - which seems to be related to gnupg2 Thunderbird and Enigmail running on a 64 bit Linux. The only error message am now getting is "bad passphrase" when I've not even entered a passphrase but am about to too. As I recall the only options I have are installing a version of Thunderbird at least 4 years older than the current version. I'm using Thunderbird 24.6.0 at the moment with the same error message - "bad passphrase" with no ability at the terminal or in Enigmail to correct or change it. Even gnupg 1.4 does not accept -passwd. As I recall I had the same problem with Fedora and Suse 14 64 bit. I'm on Linux 3.11.0-26-generic (x86_64) Ubuntu 13.10. And as I recall others had similar problems with Fedora on a 64 bit O/S. I've enclosed a copy of my private key - but as I've got rid of gnupg2 the error message "Key 0xAAD8C47D not found or not valid. The (sub-)key might of expired" has vanished. The only error message am stuck with is "bad passphrase" and no ability to sign or encrypt emails or files or anything else. So am going to install a copy of Thunderbird at least 4 years older than the current version with an appropriate Enigmail. As stated and as aa fact of daily life there are problems running a Linux distro in x86_64 there are problems with gnupg2 there are problems with Thunderbird and there are problems with Enigmail. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: david-public.key Type: application/pgp-keys Size: 4295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xAAD8C47D.asc Type: application/pgp-keys Size: 5843 bytes Desc: not available URL: From htd+ml at fritha.org Sun Nov 16 09:11:36 2014 From: htd+ml at fritha.org (Heinz Diehl) Date: Sun, 16 Nov 2014 09:11:36 +0100 Subject: The Facts: In-Reply-To: <54682F24.6060709@gbenet.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> <54682F24.6060709@gbenet.com> Message-ID: <20141116081136.GB1763@fritha.org> On 16.11.2014, david at gbenet.com wrote: > So am going to install a copy of Thunderbird at least 4 years older than the current version > with an appropriate Enigmail. > As stated and as aa fact of daily life there are problems > running a Linux distro in x86_64 there are problems with gnupg2 there are problems with > Thunderbird and there are problems with Enigmail. I have installed several 64-bit Linux distributions in the last 6 months (mainly Fedora and Arch), and most of the users have Thunderbird as their email client. All of them run gnupg, thunderbird and enigmail, and none has encountered a single problem so far. Furthermore, if you think your problems are related to Thunderbird, there's also Sylpheed, which has great gnupg support natively (and which I for myself would prefer over Thunderbird): http://sylpheed.sraoss.jp/en/ From ivangrunt09 at gmail.com Sun Nov 16 09:44:25 2014 From: ivangrunt09 at gmail.com (Larry Brower) Date: Sun, 16 Nov 2014 02:44:25 -0600 Subject: My Conclusions In-Reply-To: <5465DC99.3060803@gbenet.com> References: <5465DC99.3060803@gbenet.com> Message-ID: I have never had any issues moving keys between boxes. In fact I moved my keys just last week to a box at work. What exactly is the nature of the problem? On Friday, November 14, 2014, david at gbenet.com wrote: > Hi All, > > After spending 62 hours on what I thought would be a simple task namely to > get a fully > functioning gnupg mirror on my 64 bit Linux system - I realise this is an > impossible task to > do. In the past I've ended up creating a new set of certificates - but > this time round I > thought that I would apply some effort. > > My conclusion is It IS Impossible To Transfer Your Keys From The Same O/S > To Another Machine. > > There is no one in the entire universe that has ever attempted it. And if > they have THEY > HAVE FAILED. Not one person on this list knows how to do it successfully. > No one. NOT ONE OF > YOU can transfer a mirror image of your .gnupg folder and expect it to > work. > > This tells me what I have long suspected - yes it's good at encryption and > signing but the > programme is fundamentally flawed as to make it utter crap. My keys are > PERFECT but the > software is CRAP. Werner Koch knows it's crap. Every one knows it's crap. > > So, If I want to go on signing and encrypting my emails I HAVE TO CREATE > ANOTHER SET A > BLOODY KEYS!!!!!!!! > > I am not a happy bunny!!! > > David > > > > > -- > ?See the sanity of the man! No gods, no angels, no demons, no body. > Nothing of the > kind.Stern, sane,every brain-cell perfect and complete even at the moment > of death. No > delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriel.niebler at gmail.com Sun Nov 16 10:43:13 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Sun, 16 Nov 2014 10:43:13 +0100 Subject: The Facts: In-Reply-To: <54682F24.6060709@gbenet.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> <54682F24.6060709@gbenet.com> Message-ID: <4f4d8e84-65a3-4edc-800e-6531f3f22d3f@email.android.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David, it is not a gpg2 problem and it is also not relatd to modern versions of your mail programmes. In my case Thunderbird 31.2 with Enigmail 1.7 runs just fine with GnuPG 1.4.16. I also have GnuPG 2.0.22 installed as gpg2, but I'm not actively using it. You don't need to downgrade your Thunderbird, if it has problems signing and encrypting mail, somthing else is amiss. I now think you may be hitting the pinentry issue Philip Jackson reported several months ago. There seems to be a problem specifically with pinentry-gtk2 and IIRC that's what you're using. You're on KDE, I believe, so have you tried removing 'pinentry-gtk2' and replacing it with 'pinentry-qt4'? If that doesn't work, could you try using 'pinentry-curses'? Also, what's the content of your gpg.conf? (Just do 'cat ~/.gnupg/gpg.conf') Best gabe -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFJBAEBCgAzBQJUaHGxLBxHYWJyaWVsIE5pZWJsZXIgPGdhYnJpZWwubmllYmxl ckBnbWFpbC5jb20+AAoJEO7XEikU4kSzPx8IALStra/9pzJtLG9nL2f96mCyyy7j lZGiu0pvWqMYFGPtGg4285q/EbM/5WRRpBqVRMS1PwDixySOLpT++AMQ133bdCwz XCto9ErrT0XRZg5fnH5ON3AjDGdtZ0bvBvRcgnT3JePBu/xkPBn3DccQtnkjT1Ls XZRtL8JAhcPucKPD+2xyf2zd0LhmDPk2EdCL5fi4UNnbQ9Un7gyDlcup9/WpKQ4f GF8ljjEcFOZUpaLUnOXVzvYkDNejNe4aXvX4quLABSbLJkFQQZdsC35LxbPMiqwQ VN/FfTjJh1PmhzaX7WZExYlL93F/wyieCPqkLo84r4KwAx9Z27cM46UdTOE= =h2qY -----END PGP SIGNATURE----- From philip.jackson at nordnet.fr Sun Nov 16 17:54:18 2014 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sun, 16 Nov 2014 17:54:18 +0100 Subject: The Facts: In-Reply-To: <54682F24.6060709@gbenet.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> <54682F24.6060709@gbenet.com> Message-ID: <5468D6BA.8050009@nordnet.fr> On 16/11/14 05:59, david at gbenet.com wrote: > Werner, > > I have partly resolved the problem - which seems to be related to gnupg2 Thunderbird and > Enigmail running on a 64 bit Linux. The only error message am now getting is "bad > passphrase" when I've not even entered a passphrase but am about to too. I had this same difficulty around June this year when I migrated from Windows7 to UbuntuStudio 1404. (both 64 bit). I wanted to use gnupg2 rather than the standard gnupg1-4.-16 which was packaged with Ubuntu and the gnupg website said that gnupg1 and gnupg2 could co-exist ok on the same machine. So I installed the Ubuntu gnupg2 package 2.0.22. I had migrated my Thunderbird profile ok from Windows7 to Ubuntu and was happily using Thunderbird 24.6 and enigmail 1.6 before I installed gnupg2. Afterwards, I could not get emails to be signed. I did get the bad passphrase message without having been asked to provide one. I also got a 'no pinentry' message. I removed the Ubuntu gnupg2.0.22 package and using only gnupg1.4.16, Thunderbird and enigmail worked perfectly. I then set about learning how to install myself the latest version (at that time) which was gnupg2.0.26 with help from this list. When I got it installed, enigmail then worked perfectly. I cannot advise how to install gnupg2.0.26 - it was above my pay-grade at the time but I did manage it. And I have subsequently upgraded Thunderbird many times (now at 31.2) and enigmail too (now at 1.7.2). I confirm that on UbuntuStudio 14.04 64 bit, Thunderbird 31.2 with enigmail 1.7.2 works just fine with gnupg2.0.26. I wrote up some of my problem on launchpad (Ubuntu bug reports) and there is at least one other bug reporting similar behaviour. For further info on these, try these links : https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1332864 https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1313879 My conclusion was that there must have been some issue with the gnupg2.0.22 package as prepared and released by ubuntu. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jhs at berklix.com Sun Nov 16 18:55:24 2014 From: jhs at berklix.com (Julian H. Stacey) Date: Sun, 16 Nov 2014 18:55:24 +0100 Subject: Why the software is crap In-Reply-To: Your message "Sat, 15 Nov 2014 17:43:00 +0100." <54678294.9030903@nordnet.fr> Message-ID: <201411161755.sAGHtOQ7047237@fire.js.berklix.net> Philip Jackson wrote: > On 15/11/14 03:42, Julian H. Stacey wrote: > > Heinz Diehl wrote: > >> ||__|| | Please don't | > >> / O O\__ feed | > >> / \ the troll | > > > > Best forcibly un-subscribe . > > > > Cheers, > > Julian > > > It appears that David might well be the postmaster at gbenet.com which seems to > be a recent site apparently specializing in cryptology. What little it contains > has to be accessed via the 'sitemap'. The texts are a similar sort of rant, in > poor language with little if any punctuation. > > The name of the site recalls to me what was a popular expletive in the UK in or > around the 1970's : "Gordon Bennett!!" Yes, Gordon Bennett had sprung to my mind too (I grew up in Britain) History/ light relief: http://www.phrases.org.uk/meanings/gordon-bennett.html 'whois gbenet.com' shows nameservers in UK, lttle other info. > Best forgotten. Yes. Pref. unsubscribed too as a waster. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. From bernhard at intevation.de Mon Nov 17 10:49:09 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Nov 2014 10:49:09 +0100 Subject: GPG API: Open Crypto Engine In-Reply-To: <20141110171410cQwKOe9HNd@goodcrypto.com> References: <20141110171410cQwKOe9HNd@goodcrypto.com> Message-ID: <201411171049.15672.bernhard@intevation.de> Hi Nan, On Monday 10 November 2014 at 18:14:10, Nan wrote: > >I've added a first link to the wiki.gnupg.org in applications that use > > GnuPG. > >Do you use gpgme? > No. OCE predates GPGME. thanks for updating the wiki entry and the links to the API docs. I've streamlined the entry a little bit today. You did write that your solution is Free Software ("Open Source") do you have a link to the license for the complete solution (as compared to just the libraries). If so, it would be nice to complete this in the wiki as well. Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From mfarrior at gmail.com Sat Nov 15 19:36:17 2014 From: mfarrior at gmail.com (Maxwell Farrior) Date: Sat, 15 Nov 2014 13:36:17 -0500 Subject: card is permanently locked! Message-ID: Hello, I'm getting this error message whenever I attempt to make any change to my openpgp card. When I got the card, I changed some basic settings such as the cardholder name and sex. Then I changed the admin and user PINs. Somewhere after changing the default PINs and before loading my keys onto the card, I was asked to enter a PIN. I was unsure whether to use the user PIN or admin PIN. Whichever I used was wrong and now the card will not let me change anything else. I'm able to access the card just fine. It is a version 2.0 card. Attempting to change any attribute of the card (name, sex) gives the error: scdaemon[4189]: card is permanently locked! gpg: error setting Name: Bad PIN I was never prompted for a PIN. In the passwd menu, numbers 2 through 4 give a similar error: scdaemon[4189]: card is permanently locked! scdaemon[4189]: command passwd failed: Bad PIN Error unblocking the PIN: Bad PIN Again, I am not prompted for a PIN. Choosing number 1 on the passwd menu gives a slightly different result. First, pinentry asks "Please enter the PIN". Next, pinentry asks me for a "New PIN" and "Repeat this PIN". Finally, I get a similar error as noted above: scdaemon[4189]: command passwd failed: PIN blocked Error changing the PIN: PIN blocked When choosing number 1 on the passwd menu, I am not sure which PIN I should enter. I have tried every (known) possibility which includes the default user PIN, the default admin PIN, my own user PIN and my own admin PIN. All produce the same result. Is there any way to make my card usable? Great thanks for reading. Other (maybe) relevant info: I'm using a Debian based distro with gnupg 2.0.19. I'm using gnupg 2.0.x because I want to use 4096 bit keys on my card. When reading the data on the card, PIN retry counter has a value of 0 0 0. In other examples I've seen online, I've seen this value as 3 0 3. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at gbenet.com Mon Nov 17 12:20:05 2014 From: david at gbenet.com (david at gbenet.com) Date: Mon, 17 Nov 2014 11:20:05 +0000 Subject: The Facts: In-Reply-To: <4f4d8e84-65a3-4edc-800e-6531f3f22d3f@email.android.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> <54682F24.6060709@gbenet.com> <4f4d8e84-65a3-4edc-800e-6531f3f22d3f@email.android.com> Message-ID: <5469D9E5.7040108@gbenet.com> On 16/11/14 09:43, Gabriel Niebler wrote: > David, > > it is not a gpg2 problem and it is also not relatd to modern versions > of your mail programmes. In my case Thunderbird 31.2 with > Enigmail 1.7 runs just fine with GnuPG 1.4.16. I also have GnuPG > 2.0.22 installed as gpg2, but I'm not actively using it. You don't need > to downgrade your Thunderbird, if it has problems signing and > encrypting mail, somthing else is amiss. > > I now think you may be hitting the pinentry issue Philip Jackson > reported several months ago. There seems to be a problem specifically > with pinentry-gtk2 and IIRC that's what you're using. You're on KDE, I > believe, so have you tried removing 'pinentry-gtk2' and replacing it > with 'pinentry-qt4'? If that doesn't work, could you try using > 'pinentry-curses'? > > Also, what's the content of your gpg.conf? (Just do 'cat > ~/.gnupg/gpg.conf') > > Best > gabe > > Gabriel, I had to reinstall again my 64 bit LXDE Linux. I created a brand new .gnupg folder and imported my private and public key. They are the only keys I have. But am stuck with the issue of "bad passphrase" I can not edit my keys - in fact I can't change anything with my keys. I don't even have gpg2 installed. So am writing on my trusty 32 bit LXDE Linux. I have no idea what's going on. I'm on Ubuntu LXDE. On both laptops. I will try your suggestions. I applied all your suggestions but still get "bad passphrase" the contents of my gpg.conf: david at laptop-2:~$ cat ~/.gnupg/gpg.conf # Options for GnuPG # Copyright 1998, 1999, 2000, 2001, 2002, 2003, # 2010 Free Software Foundation, Inc. # # This file is free software; as a special exception the author gives # unlimited permission to copy and/or distribute it, with or without # modifications, as long as this notice is preserved. # # This file is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # # Unless you specify which option file to use (with the command line # option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf # by default. # # An options file can contain any long options which are available in # GnuPG. If the first non white space character of a line is a '#', # this line is ignored. Empty lines are also ignored. # # See the man page for a list of options. # Uncomment the following option to get rid of the copyright notice #no-greeting # If you have more than 1 secret key in your keyring, you may want to # uncomment the following option and set your preferred keyid. #default-key 621CC013 # If you do not pass a recipient to gpg, it will ask for one. Using # this option you can encrypt to a default key. Key validation will # not be done in this case. The second form uses the default key as # default recipient. #default-recipient some-user-id #default-recipient-self # Use --encrypt-to to add the specified key as a recipient to all # messages. This is useful, for example, when sending mail through a # mail client that does not automatically encrypt mail to your key. # In the example, this option allows you to read your local copy of # encrypted mail that you've sent to others. #encrypt-to some-key-id # By default GnuPG creates version 4 signatures for data files as # specified by OpenPGP. Some earlier (PGP 6, PGP 7) versions of PGP # require the older version 3 signatures. Setting this option forces # GnuPG to create version 3 signatures. #force-v3-sigs # Because some mailers change lines starting with "From " to ">From " # it is good to handle such lines in a special way when creating # cleartext signatures; all other PGP versions do it this way too. #no-escape-from-lines # If you do not use the Latin-1 (ISO-8859-1) charset, you should tell # GnuPG which is the native character set. Please check the man page # for supported character sets. This character set is only used for # metadata and not for the actual message which does not undergo any # translation. Note that future version of GnuPG will change to UTF-8 # as default character set. In most cases this option is not required # as GnuPG is able to figure out the correct charset at runtime. #charset utf-8 # Group names may be defined like this: # group mynames = paige 0x12345678 joe patti # # Any time "mynames" is a recipient (-r or --recipient), it will be # expanded to the names "paige", "joe", and "patti", and the key ID # "0x12345678". Note there is only one level of expansion - you # cannot make an group that points to another group. Note also that # if there are spaces in the recipient name, this will appear as two # recipients. In these cases it is better to use the key ID. #group mynames = paige 0x12345678 joe patti # Lock the file only once for the lifetime of a process. If you do # not define this, the lock will be obtained and released every time # it is needed, which is usually preferable. #lock-once # GnuPG can send and receive keys to and from a keyserver. These # servers can be HKP, email, or LDAP (if GnuPG is built with LDAP # support). # # Example HKP keyserver: # hkp://keys.gnupg.net # hkp://subkeys.pgp.net # # Example email keyserver: # mailto:pgp-public-keys at keys.pgp.net # # Example LDAP keyservers: # ldap://keyserver.pgp.com # # Regular URL syntax applies, and you can set an alternate port # through the usual method: # hkp://keyserver.example.net:22742 # # Most users just set the name and type of their preferred keyserver. # Note that most servers (with the notable exception of # ldap://keyserver.pgp.com) synchronize changes with each other. Note # also that a single server name may actually point to multiple # servers via DNS round-robin. hkp://keys.gnupg.net is an example of # such a "server", which spreads the load over a number of physical # servers. To see the IP address of the server actually used, you may use # the "--keyserver-options debug". keyserver hkp://keys.gnupg.net #keyserver mailto:pgp-public-keys at keys.nl.pgp.net #keyserver ldap://keyserver.pgp.com # Common options for keyserver functions: # # include-disabled : when searching, include keys marked as "disabled" # on the keyserver (not all keyservers support this). # # no-include-revoked : when searching, do not include keys marked as # "revoked" on the keyserver. # # verbose : show more information as the keys are fetched. # Can be used more than once to increase the amount # of information shown. # # use-temp-files : use temporary files instead of a pipe to talk to the # keyserver. Some platforms (Win32 for one) always # have this on. # # keep-temp-files : do not delete temporary files after using them # (really only useful for debugging) # # http-proxy="proxy" : set the proxy to use for HTTP and HKP keyservers. # This overrides the "http_proxy" environment variable, # if any. # # auto-key-retrieve : automatically fetch keys as needed from the keyserver # when verifying signatures or when importing keys that # have been revoked by a revocation key that is not # present on the keyring. # # no-include-attributes : do not include attribute IDs (aka "photo IDs") # when sending keys to the keyserver. #keyserver-options auto-key-retrieve # Display photo user IDs in key listings # list-options show-photos # Display photo user IDs when a signature from a key with a photo is # verified # verify-options show-photos # Use this program to display photo user IDs # # %i is expanded to a temporary file that contains the photo. # %I is the same as %i, but the file isn't deleted afterwards by GnuPG. # %k is expanded to the key ID of the key. # %K is expanded to the long OpenPGP key ID of the key. # %t is expanded to the extension of the image (e.g. "jpg"). # %T is expanded to the MIME type of the image (e.g. "image/jpeg"). # %f is expanded to the fingerprint of the key. # %% is %, of course. # # If %i or %I are not present, then the photo is supplied to the # viewer on standard input. If your platform supports it, standard # input is the best way to do this as it avoids the time and effort in # generating and then cleaning up a secure temp file. # # If no photo-viewer is provided, GnuPG will look for xloadimage, eog, # or display (ImageMagick). On Mac OS X and Windows, the default is # to use your regular JPEG image viewer. # # Some other viewers: # photo-viewer "qiv %i" # photo-viewer "ee %i" # # This one saves a copy of the photo ID in your home directory: # photo-viewer "cat > ~/photoid-for-key-%k.%t" # # Use your MIME handler to view photos: # photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG" # Passphrase agent # # We support the old experimental passphrase agent protocol as well as # the new Assuan based one (currently available in the "newpg" package # at ftp.gnupg.org/gcrypt/alpha/aegypten/). To make use of the agent, # you have to run an agent as daemon and use the option # # For Ubuntu we now use-agent by default to support more automatic # use of GPG and S/MIME encryption by GUI programs. Depending on the # program, users may still have to manually decide to install gnupg-agent. use-agent # which tries to use the agent but will fallback to the regular mode # if there is a problem connecting to the agent. The normal way to # locate the agent is by looking at the environment variable # GPG_AGENT_INFO which should have been set during gpg-agent startup. # In certain situations the use of this variable is not possible, thus # the option # # --gpg-agent-info=::1 # # may be used to override it. # Automatic key location # # GnuPG can automatically locate and retrieve keys as needed using the # auto-key-locate option. This happens when encrypting to an email # address (in the "user at example.com" form), and there are no # user at example.com keys on the local keyring. This option takes the # following arguments, in the order they are to be tried: # # cert = locate a key using DNS CERT, as specified in RFC-4398. # GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint) # CERT methods. # # pka = locate a key using DNS PKA. # # ldap = locate a key using the PGP Universal method of checking # "ldap://keys.(thedomain)". For example, encrypting to # user at example.com will check ldap://keys.example.com. # # keyserver = locate a key using whatever keyserver is defined using # the keyserver option. # # You may also list arbitrary keyservers here by URL. # # Try CERT, then PKA, then LDAP, then hkp://subkeys.net: #auto-key-locate cert pka ldap hkp://subkeys.pgp.net david at laptop-2:~$ I had the same problem with Fedora-16 64 bit. All these people who keep saying they have had no problems do not make any contributions at all. I don't care if your system works - mine does not. The question is why on a Ubuntu LXDE 32 bit laptop my keys work - and on a Ubuntu LXDE 64 bit laptop I can not sign I can not encrypt? My private key was created and signed on a 32 bit Linux system - which fails to do anything on a 64 bit system. And when I don't install gpg2 I only now get one problem "bad passphrase." These are real "facts of life" that am having to deal with. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xAAD8C47D.asc Type: application/pgp-keys Size: 4295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From tristan.santore at internexusconnect.net Mon Nov 17 12:31:17 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Mon, 17 Nov 2014 12:31:17 +0100 Subject: The Facts: In-Reply-To: <5469D9E5.7040108@gbenet.com> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> <54682F24.6060709@gbenet.com> <4f4d8e84-65a3-4edc-800e-6531f3f22d3f@email.android.com> <5469D9E5.7040108@gbenet.com> Message-ID: <5469DC85.4090305@internexusconnect.net> On 17/11/14 12:20, david at gbenet.com wrote: > On 16/11/14 09:43, Gabriel Niebler wrote: >> David, >> >> it is not a gpg2 problem and it is also not relatd to modern versions >> of your mail programmes. In my case Thunderbird 31.2 with >> Enigmail 1.7 runs just fine with GnuPG 1.4.16. I also have GnuPG >> 2.0.22 installed as gpg2, but I'm not actively using it. You don't need >> to downgrade your Thunderbird, if it has problems signing and >> encrypting mail, somthing else is amiss. >> >> I now think you may be hitting the pinentry issue Philip Jackson >> reported several months ago. There seems to be a problem specifically >> with pinentry-gtk2 and IIRC that's what you're using. You're on KDE, I >> believe, so have you tried removing 'pinentry-gtk2' and replacing it >> with 'pinentry-qt4'? If that doesn't work, could you try using >> 'pinentry-curses'? >> >> Also, what's the content of your gpg.conf? (Just do 'cat >> ~/.gnupg/gpg.conf') >> >> Best >> gabe >> >> > Gabriel, > > I had to reinstall again my 64 bit LXDE Linux. I created a brand new .gnupg folder and > imported my private and public key. They are the only keys I have. > > But am stuck with the issue of "bad passphrase" I can not edit my keys - in fact I can't > change anything with my keys. I don't even have gpg2 installed. So am writing on my trusty > 32 bit LXDE Linux. > > I have no idea what's going on. I'm on Ubuntu LXDE. On both laptops. I will try your > suggestions. > > I applied all your suggestions but still get "bad passphrase" the contents of my gpg.conf: > > david at laptop-2:~$ cat ~/.gnupg/gpg.conf > # Options for GnuPG > # Copyright 1998, 1999, 2000, 2001, 2002, 2003, > # 2010 Free Software Foundation, Inc. > # > # This file is free software; as a special exception the author gives > # unlimited permission to copy and/or distribute it, with or without > # modifications, as long as this notice is preserved. > # > # This file is distributed in the hope that it will be useful, but > # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the > # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > # > # Unless you specify which option file to use (with the command line > # option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf > # by default. > # > # An options file can contain any long options which are available in > # GnuPG. If the first non white space character of a line is a '#', > # this line is ignored. Empty lines are also ignored. > # > # See the man page for a list of options. > > # Uncomment the following option to get rid of the copyright notice > > #no-greeting > > # If you have more than 1 secret key in your keyring, you may want to > # uncomment the following option and set your preferred keyid. > > #default-key 621CC013 > > # If you do not pass a recipient to gpg, it will ask for one. Using > # this option you can encrypt to a default key. Key validation will > # not be done in this case. The second form uses the default key as > # default recipient. > > #default-recipient some-user-id > #default-recipient-self > > # Use --encrypt-to to add the specified key as a recipient to all > # messages. This is useful, for example, when sending mail through a > # mail client that does not automatically encrypt mail to your key. > # In the example, this option allows you to read your local copy of > # encrypted mail that you've sent to others. > > #encrypt-to some-key-id > > # By default GnuPG creates version 4 signatures for data files as > # specified by OpenPGP. Some earlier (PGP 6, PGP 7) versions of PGP > # require the older version 3 signatures. Setting this option forces > # GnuPG to create version 3 signatures. > > #force-v3-sigs > > # Because some mailers change lines starting with "From " to ">From " > # it is good to handle such lines in a special way when creating > # cleartext signatures; all other PGP versions do it this way too. > > #no-escape-from-lines > > # If you do not use the Latin-1 (ISO-8859-1) charset, you should tell > # GnuPG which is the native character set. Please check the man page > # for supported character sets. This character set is only used for > # metadata and not for the actual message which does not undergo any > # translation. Note that future version of GnuPG will change to UTF-8 > # as default character set. In most cases this option is not required > # as GnuPG is able to figure out the correct charset at runtime. > > #charset utf-8 > > # Group names may be defined like this: > # group mynames = paige 0x12345678 joe patti > # > # Any time "mynames" is a recipient (-r or --recipient), it will be > # expanded to the names "paige", "joe", and "patti", and the key ID > # "0x12345678". Note there is only one level of expansion - you > # cannot make an group that points to another group. Note also that > # if there are spaces in the recipient name, this will appear as two > # recipients. In these cases it is better to use the key ID. > > #group mynames = paige 0x12345678 joe patti > > # Lock the file only once for the lifetime of a process. If you do > # not define this, the lock will be obtained and released every time > # it is needed, which is usually preferable. > > #lock-once > > # GnuPG can send and receive keys to and from a keyserver. These > # servers can be HKP, email, or LDAP (if GnuPG is built with LDAP > # support). > # > # Example HKP keyserver: > # hkp://keys.gnupg.net > # hkp://subkeys.pgp.net > # > # Example email keyserver: > # mailto:pgp-public-keys at keys.pgp.net > # > # Example LDAP keyservers: > # ldap://keyserver.pgp.com > # > # Regular URL syntax applies, and you can set an alternate port > # through the usual method: > # hkp://keyserver.example.net:22742 > # > # Most users just set the name and type of their preferred keyserver. > # Note that most servers (with the notable exception of > # ldap://keyserver.pgp.com) synchronize changes with each other. Note > # also that a single server name may actually point to multiple > # servers via DNS round-robin. hkp://keys.gnupg.net is an example of > # such a "server", which spreads the load over a number of physical > # servers. To see the IP address of the server actually used, you may use > # the "--keyserver-options debug". > > keyserver hkp://keys.gnupg.net > #keyserver mailto:pgp-public-keys at keys.nl.pgp.net > #keyserver ldap://keyserver.pgp.com > > # Common options for keyserver functions: > # > # include-disabled : when searching, include keys marked as "disabled" > # on the keyserver (not all keyservers support this). > # > # no-include-revoked : when searching, do not include keys marked as > # "revoked" on the keyserver. > # > # verbose : show more information as the keys are fetched. > # Can be used more than once to increase the amount > # of information shown. > # > # use-temp-files : use temporary files instead of a pipe to talk to the > # keyserver. Some platforms (Win32 for one) always > # have this on. > # > # keep-temp-files : do not delete temporary files after using them > # (really only useful for debugging) > # > # http-proxy="proxy" : set the proxy to use for HTTP and HKP keyservers. > # This overrides the "http_proxy" environment variable, > # if any. > # > # auto-key-retrieve : automatically fetch keys as needed from the keyserver > # when verifying signatures or when importing keys that > # have been revoked by a revocation key that is not > # present on the keyring. > # > # no-include-attributes : do not include attribute IDs (aka "photo IDs") > # when sending keys to the keyserver. > > #keyserver-options auto-key-retrieve > > # Display photo user IDs in key listings > > # list-options show-photos > > # Display photo user IDs when a signature from a key with a photo is > # verified > > # verify-options show-photos > > # Use this program to display photo user IDs > # > # %i is expanded to a temporary file that contains the photo. > # %I is the same as %i, but the file isn't deleted afterwards by GnuPG. > # %k is expanded to the key ID of the key. > # %K is expanded to the long OpenPGP key ID of the key. > # %t is expanded to the extension of the image (e.g. "jpg"). > # %T is expanded to the MIME type of the image (e.g. "image/jpeg"). > # %f is expanded to the fingerprint of the key. > # %% is %, of course. > # > # If %i or %I are not present, then the photo is supplied to the > # viewer on standard input. If your platform supports it, standard > # input is the best way to do this as it avoids the time and effort in > # generating and then cleaning up a secure temp file. > # > # If no photo-viewer is provided, GnuPG will look for xloadimage, eog, > # or display (ImageMagick). On Mac OS X and Windows, the default is > # to use your regular JPEG image viewer. > # > # Some other viewers: > # photo-viewer "qiv %i" > # photo-viewer "ee %i" > # > # This one saves a copy of the photo ID in your home directory: > # photo-viewer "cat > ~/photoid-for-key-%k.%t" > # > # Use your MIME handler to view photos: > # photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG" > > # Passphrase agent > # > # We support the old experimental passphrase agent protocol as well as > # the new Assuan based one (currently available in the "newpg" package > # at ftp.gnupg.org/gcrypt/alpha/aegypten/). To make use of the agent, > # you have to run an agent as daemon and use the option > # > # For Ubuntu we now use-agent by default to support more automatic > # use of GPG and S/MIME encryption by GUI programs. Depending on the > # program, users may still have to manually decide to install gnupg-agent. > > use-agent > > # which tries to use the agent but will fallback to the regular mode > # if there is a problem connecting to the agent. The normal way to > # locate the agent is by looking at the environment variable > # GPG_AGENT_INFO which should have been set during gpg-agent startup. > # In certain situations the use of this variable is not possible, thus > # the option > # > # --gpg-agent-info=::1 > # > # may be used to override it. > > # Automatic key location > # > # GnuPG can automatically locate and retrieve keys as needed using the > # auto-key-locate option. This happens when encrypting to an email > # address (in the "user at example.com" form), and there are no > # user at example.com keys on the local keyring. This option takes the > # following arguments, in the order they are to be tried: > # > # cert = locate a key using DNS CERT, as specified in RFC-4398. > # GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint) > # CERT methods. > # > # pka = locate a key using DNS PKA. > # > # ldap = locate a key using the PGP Universal method of checking > # "ldap://keys.(thedomain)". For example, encrypting to > # user at example.com will check ldap://keys.example.com. > # > # keyserver = locate a key using whatever keyserver is defined using > # the keyserver option. > # > # You may also list arbitrary keyservers here by URL. > # > # Try CERT, then PKA, then LDAP, then hkp://subkeys.net: > #auto-key-locate cert pka ldap hkp://subkeys.pgp.net > david at laptop-2:~$ > > > I had the same problem with Fedora-16 64 bit. All these people who keep saying they have had > no problems do not make any contributions at all. I don't care if your system works - mine > does not. The question is why on a Ubuntu LXDE 32 bit laptop my keys work - and on a Ubuntu > LXDE 64 bit laptop I can not sign I can not encrypt? My private key was created and signed > on a 32 bit Linux system - which fails to do anything on a 64 bit system. And when I don't > install gpg2 I only now get one problem "bad passphrase." These are real "facts of life" > that am having to deal with. > > David > > > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > David, you really need to get into the habit of mentioning exact version numbers, and produce some output, as you see it in the shell. It is virtually impossible to help anyone without further information. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org From david at gbenet.com Mon Nov 17 12:32:42 2014 From: david at gbenet.com (david at gbenet.com) Date: Mon, 17 Nov 2014 11:32:42 +0000 Subject: The Facts: In-Reply-To: <5468D6BA.8050009@nordnet.fr> References: <54673E62.6030506__16564.9677430794$1416052437$gmane$org@gbenet.com> <546786C7.5030702@enigmail.net> <54678A7B.8050400@gbenet.com> <54679711.9060305@vulcan.xs4all.nl> <87sihkrz4c.fsf@vigenere.g10code.de> <54682F24.6060709@gbenet.com> <5468D6BA.8050009@nordnet.fr> Message-ID: <5469DCDA.9090303@gbenet.com> On 16/11/14 16:54, Philip Jackson wrote: > On 16/11/14 05:59, david at gbenet.com wrote: >> Werner, >> >> I have partly resolved the problem - which seems to be related to gnupg2 Thunderbird and >> Enigmail running on a 64 bit Linux. The only error message am now getting is "bad >> passphrase" when I've not even entered a passphrase but am about to too. > > I had this same difficulty around June this year when I migrated from Windows7 > to UbuntuStudio 1404. (both 64 bit). > > I wanted to use gnupg2 rather than the standard gnupg1-4.-16 which was packaged > with Ubuntu and the gnupg website said that gnupg1 and gnupg2 could co-exist ok > on the same machine. So I installed the Ubuntu gnupg2 package 2.0.22. > > I had migrated my Thunderbird profile ok from Windows7 to Ubuntu and was happily > using Thunderbird 24.6 and enigmail 1.6 before I installed gnupg2. Afterwards, > I could not get emails to be signed. I did get the bad passphrase message > without having been asked to provide one. I also got a 'no pinentry' message. > > I removed the Ubuntu gnupg2.0.22 package and using only gnupg1.4.16, Thunderbird > and enigmail worked perfectly. > > I then set about learning how to install myself the latest version (at that > time) which was gnupg2.0.26 with help from this list. When I got it installed, > enigmail then worked perfectly. > > I cannot advise how to install gnupg2.0.26 - it was above my pay-grade at the > time but I did manage it. And I have subsequently upgraded Thunderbird many > times (now at 31.2) and enigmail too (now at 1.7.2). I confirm that on > UbuntuStudio 14.04 64 bit, Thunderbird 31.2 with enigmail 1.7.2 works just fine > with gnupg2.0.26. > > I wrote up some of my problem on launchpad (Ubuntu bug reports) and there is at > least one other bug reporting similar behaviour. For further info on these, try > these links : > > https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1332864 > https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1313879 > > My conclusion was that there must have been some issue with the gnupg2.0.22 > package as prepared and released by ubuntu. > > Philip > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Hi Philip, I have not installed gnupg2 on my new Ubuntu LXDE 64 bit laptop. But am still stuck with "bad passphrase" until I get that resolved I'll not be installing gnupg2 from the web site. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Nov 17 12:32:45 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Nov 2014 12:32:45 +0100 Subject: Error message "Ohhhh jeeee: ... this is a bug" In-Reply-To: <629851038.20141115194527@my_localhost> (MFPA's message of "Sat, 15 Nov 2014 19:45:27 +0000") References: <629851038.20141115194527@my_localhost> Message-ID: <87ppcmqcyq.fsf@vigenere.g10code.de> On Sat, 15 Nov 2014 20:45, 2014-667rhzu3dc-lists-groups at riseup.net said: > I just got the following error messages from Gnupg 2.1 and Windows > XP:- That does not look like a Windows specific problem. However, I can't replicate it. > gpg --no-options --no-default-keyring --import "C:\Documents and > Settings\Administrator\Application Data\GnuPG\secring.gpg" Using --no-default-keyring is superfluous if you do not specify another keyring. gpg will in this case use teh default keyring anyway. > I have tried the command again and got the same error message. Then I > ran it again with --debug-all; I can forward the output but will > not post itin the clear to the list. --full-debug may reveal your secret key - do not send it. Can you produce a test case using sample keys? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nan at goodcrypto.com Mon Nov 17 13:33:33 2014 From: nan at goodcrypto.com (Nan) Date: Mon, 17 Nov 2014 12:33:33 GMT Subject: GPG API: Open Crypto Engine Message-ID: <20141117123333r0zhFV1NVJ@goodcrypto.com> Thanks, Bernhard. I'll update the wiki with the link. GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From wk at gnupg.org Mon Nov 17 14:54:35 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Nov 2014 14:54:35 +0100 Subject: [admin] Please strip your quotes Message-ID: <87h9xyq6ec.fsf@vigenere.g10code.de> Hi, during this long-winded process of trying to help a guy here, I noticed that the habit of some of us, not to strip quotes to a few lines (and to leave a blank line after a quote). It is time consuming to scroll down some pages just to see that a few lines of content. And not you have to do that but 2000 other subscribers as well. Please strip quotes the next time even if you feel annoyed by some postings. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 17 14:55:50 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Nov 2014 14:55:50 +0100 Subject: GPG API: Open Crypto Engine In-Reply-To: <20141117123333r0zhFV1NVJ@goodcrypto.com> (nan@goodcrypto.com's message of "Mon, 17 Nov 2014 12:33:33 GMT") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> Message-ID: <87d28mq6c9.fsf@vigenere.g10code.de> On Mon, 17 Nov 2014 13:33, nan at goodcrypto.com said: > GoodCrypto warning: Anyone could have read this message. Use encryption, it works. That does not make any sense on a public mailling liost. We write here for the public - it is non-encrypted for a purpose. scnr, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dgouttegattat at incenp.org Mon Nov 17 17:08:37 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Mon, 17 Nov 2014 17:08:37 +0100 Subject: card is permanently locked! In-Reply-To: References: Message-ID: <546A1D85.9070808@incenp.org> On 11/15/2014 07:36 PM, Maxwell Farrior wrote: > Is there any way to make my card usable? Great thanks for reading. According to the specification [1], yes, but it involves resetting the card completely. Once the card is ?permanently blocked? (which is indicated by the fact that the retry counters for both User and Admin PIN are at zero), it is possible to send to the card a ?TERMINATE DF? command to put it back into the initialisation state, then a ?ACTIVATE FILE? command to reset all stored values (including PINs) to their default values. With gpg-agent and scdaemon running, you should be able to do that with the following commands: $ gpg-connect-agent > SCD APDU 00 e6 00 00 > SCD APDU 00 44 00 00 > /bye Disclaimer: I?ve never actually tried that, but that?s what I would do in such a case after reading the specs. I guess that with a ?permanently blocked? card, one does not have much to lose? [1] http://g10code.com/docs/openpgp-card-2.0.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From nan at goodcrypto.com Mon Nov 17 17:38:15 2014 From: nan at goodcrypto.com (Nan) Date: Mon, 17 Nov 2014 16:38:15 GMT Subject: GPG API: Open Crypto Engine Message-ID: <20141117163815KBQcLhMmpZ@goodcrypto.com> Hi Werner, All email I send goes through the GoodCrypto Server. If I don't have a key for the recipient, then the tag is automatically added to encourage others to use encryption. Clearly, folks on this mailing list already understand the importance of encryption. Currently, there's no flag to designate that some recipient addresses are mailing lists related to encryption. If others using the GoodCrypto Server thinks that's a valuable additional, we'll likely add it in the future. Werner, let me take a moment and thank you for your years of work on GPG. Given the revelations over the past 1.5 years, we think everyone should be using it. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From m.mansfeld at mansfeld-elektronik.de Mon Nov 17 17:10:16 2014 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Mon, 17 Nov 2014 17:10:16 +0100 Subject: Encryption on Mailing lists sensless? (was: Re: GPG API: Open Crypto Engine) In-Reply-To: <87d28mq6c9.fsf@vigenere.g10code.de> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> Message-ID: <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> Zitat von Werner Koch : > On Mon, 17 Nov 2014 13:33, nan at goodcrypto.com said: > >> GoodCrypto warning: Anyone could have read this message. Use >> encryption, it works. > > That does not make any sense on a public mailling list. We write here > for the public - it is non-encrypted for a purpose. > > scnr, ... Er, this is Nan's Signature for everything. Maybe he shoud ad the usual -- above. But sorry, I disagree a little bit. If we want literally to jam the secret service's attempts to decrypt mails, then it makes sense to use encryption for every single mail, private, business, nonsense and spam.... Technical reasons, NOT to encrypt on a list server are another disussion. Best regards Matthias -- Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de GPG http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc From rjh at sixdemonbag.org Mon Nov 17 18:02:07 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 17 Nov 2014 12:02:07 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> Message-ID: <546A2A0F.3020704@sixdemonbag.org> > But sorry, I disagree a little bit. If we want literally to jam the > secret service's attempts to decrypt mails, then it makes sense to use > encryption for every single mail, private, business, nonsense and spam.... This would have the ultimate effect of destroying email as a platform. Email works as well as it does -- as well as fails so miserably in other ways -- largely *because* it's open to inspection. As an example, pervasive end-to-end encryption would require antispam defenses to move to the client rather than being deployed at the mailserver or relay. This would essentially be tantamount to giving up, since there are no really effective client-side antispam measures. Similarly, it would assist in the spread of malware and viruses and for the same reasons. If a mailserver can't inspect the email, it can't recognize malware and quarantine it for the health of the internet. Etc., etc. I am fanatically in favor of people's right to protect the privacy of their communications, but there's a flipside to it: we also need to be responsible and prudent with how we do it. Simple, naive solutions like "encrypt everything!" aren't a fix: at best, they'll trade our current set of problems for a new set of problems which we'll have even less knowledge of how to handle. From allan at archlinux.org Mon Nov 17 16:44:38 2014 From: allan at archlinux.org (Allan McRae) Date: Tue, 18 Nov 2014 01:44:38 +1000 Subject: Receiving keys as root user Message-ID: <546A17E6.5040302@archlinux.org> I have a GPG keychain for the root user which is used to validate all files in my package management system. To add a key into this key chain, I have been running: sudo gpg --homedir /etc/pacman.d/gnupg/ --recv-keys EAE999BD With the 2.1 release, this now give the following error: gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC connect call failed gpg: keyserver receive failed: No dirmngr Is there a way to handle this that I am missing or is it a bug? Thanks, Allan From ineiev at gnu.org Mon Nov 17 17:04:10 2014 From: ineiev at gnu.org (Ineiev) Date: Mon, 17 Nov 2014 11:04:10 -0500 Subject: GPG API: Open Crypto Engine In-Reply-To: <87d28mq6c9.fsf@vigenere.g10code.de> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> Message-ID: <20141117160409.GA27480@gnu.org> On Mon, Nov 17, 2014 at 02:55:50PM +0100, Werner Koch wrote: > On Mon, 17 Nov 2014 13:33, nan at goodcrypto.com said: > > > GoodCrypto warning: Anyone could have read this message. Use encryption, it works. > > That does not make any sense on a public mailling liost. We write here > for the public - it is non-encrypted for a purpose. Would it make any sense on a private mailing list? From aarcane at aarcane.org Mon Nov 17 18:48:48 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Mon, 17 Nov 2014 09:48:48 -0800 Subject: Encryption on Mailing lists sensless? (was: Re: GPG API: Open Crypto Engine) In-Reply-To: <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> Message-ID: Most of the technical reasons can be bypassed by making a single subscriber key (public and private) available as a part of the subscription process, but that eliminates most of the technical advantages of encryption, so it's really a moot point. On Nov 17, 2014 8:52 AM, "Matthias Mansfeld" < m.mansfeld at mansfeld-elektronik.de> wrote: > Zitat von Werner Koch : > > On Mon, 17 Nov 2014 13:33, nan at goodcrypto.com said: >> >> GoodCrypto warning: Anyone could have read this message. Use encryption, >>> it works. >>> >> >> That does not make any sense on a public mailling list. We write here >> for the public - it is non-encrypted for a purpose. >> >> scnr, >> > > ... Er, this is Nan's Signature for everything. Maybe he shoud ad the > usual -- above. > > But sorry, I disagree a little bit. If we want literally to jam the secret > service's attempts to decrypt mails, then it makes sense to use encryption > for every single mail, private, business, nonsense and spam.... > > Technical reasons, NOT to encrypt on a list server are another disussion. > > Best regards > Matthias > -- > Matthias Mansfeld Elektronik * Leiterplattenlayout > Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 > Internet: http://www.mansfeld-elektronik.de > GPG http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at gbenet.com Mon Nov 17 18:48:56 2014 From: david at gbenet.com (david at gbenet.com) Date: Mon, 17 Nov 2014 17:48:56 +0000 Subject: Update Message-ID: <546A3508.4010604@gbenet.com> Having spent many many days on this problem I have failed to come with any working solution. Running a 64 bit version of LUbuntu does not work. This is a real fact of life no matter what all you people say. It does not work for me. I have tried Fedora-16 64 bit in the past - it failed - I tried Suse-14 64 bit in the past and it too failed. And now LUbuntu 64 bit fails too. My only option is to install a 32 bit Linux O/S and a 64 bit laptop. Or wipe the partition and give it all to Windoz. Thank you for putting up with my ravings and my frustrations and I thank the very very small band of people that offered practical help. All I do know is: (1) When I remove gnupg2 from Enigmail all but one problem goes away. (2) Then up stuck with "bad passphrase" without even entering the passphrase. (3) 32 bit Linux works fine for me (4) 64 bit Linux does not work for me. For those of you that can not accept reality see a psychiatrist. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Nov 17 19:13:24 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Nov 2014 19:13:24 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: (Christ Schlacta's message of "Mon, 17 Nov 2014 09:48:48 -0800") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> Message-ID: <87mw7ppuez.fsf@vigenere.g10code.de> On Mon, 17 Nov 2014 18:48, aarcane at aarcane.org said: > Most of the technical reasons can be bypassed by making a single subscriber > key (public and private) available as a part of the subscription process, And by that you would disrupt the open discussion and knowledge culture and return to an invitation only BBS network. The mailing lists are archived and indexed to spread knowledge and not to lock out most people. Private mailing lists are of course a different thing. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From aarcane at aarcane.org Mon Nov 17 19:26:31 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Mon, 17 Nov 2014 10:26:31 -0800 Subject: Encryption on Mailing lists sensless? In-Reply-To: <87mw7ppuez.fsf@vigenere.g10code.de> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <87mw7ppuez.fsf@vigenere.g10code.de> Message-ID: I wouldn't say invite only. Contrarywise, when you send the subscribe email, in the immediate, automatic response would be the public and private key, optionally encrypted to the recipient. Open enrollment, public availability. Just making the data obfuscated in transit. On Nov 17, 2014 10:15 AM, "Werner Koch" wrote: > On Mon, 17 Nov 2014 18:48, aarcane at aarcane.org said: > > Most of the technical reasons can be bypassed by making a single > subscriber > > key (public and private) available as a part of the subscription process, > > And by that you would disrupt the open discussion and knowledge culture > and return to an invitation only BBS network. The mailing lists are > archived and indexed to spread knowledge and not to lock out most > people. > > Private mailing lists are of course a different thing. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Nov 17 19:49:01 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 17 Nov 2014 13:49:01 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> Message-ID: <546A431D.1060607@sixdemonbag.org> > Most of the technical reasons can be bypassed by making a single > subscriber key (public and private) available as a part of the > subscription process, but that eliminates most of the technical > advantages of encryption, so it's really a moot point. It also means there's pretty much no point in keeping archives, because it's inevitable that the keys will become separated from the archives. And if the key is part of the archive, then what's the purpose of the crypto in the first place? Once, for my job, I had to look into the way the Roman Senate conducted its elections. I was able to find ballots that were over 1500 years old. It was pretty neat, and it changed my perspective on things like crypto. The crypto dream is that the confidentiality of our messages will be preserved for centuries after our death, which sounds really great up until you consider what an archaeologist circa 4000 AD is going to be thinking. "I have a stack of records here that could shed light on the way people lived in a long-dead civilization, but I can't read them. Why? What were these people doing that they thought their email to their Aunt Edna needed to remain secret for all time? Why is it that, millennia after they're gone, Aunt Edna's recipe for potato salad has to be gone with them?" Or think about your own kids, circa 2040 AD. "I'd love to read these emails between Mom and Dad when they were courting, but ... they were afraid of Somebody-with-an-S reading their emails. I wonder if they ever thought that the Somebody might be their son, who wanted to understand after their deaths how it was these two people came to meet and fall in love." Historians called the early medieval period "the Dark Ages" not because the era was full of villainy and evil, but because record-keeping became so austere that we really don't know much of what happened for that period. Much like dark matter (matter, but we don't know anything about it, hence it's dark), dark energy (energy, but we don't know anything about it, hence it's dark), the Dark Ages are an era we know little about. We're living in a new Dark Age right now. Historians of the future are going to see human record-keeping basically end around 1960. Fewer records were printed out and more were put on digital media -- media that deteriorates much more quickly than paper, and depends on technology to read it, technologies which become obsolete and are discarded even faster than the media degrades. So when you hear people advocate "crypto everywhere, always, for everything," ask yourself this: if they get what they want, what will it do to future generations' ability to make sense of our time? From pete at heypete.com Mon Nov 17 20:15:09 2014 From: pete at heypete.com (Pete Stephenson) Date: Mon, 17 Nov 2014 20:15:09 +0100 Subject: card is permanently locked! In-Reply-To: <546A1D85.9070808@incenp.org> References: <546A1D85.9070808@incenp.org> Message-ID: On Mon, Nov 17, 2014 at 5:08 PM, Damien Goutte-Gattat wrote: [snip] > With gpg-agent and scdaemon running, you should be able to do that with > the following commands: > > $ gpg-connect-agent >> SCD APDU 00 e6 00 00 >> SCD APDU 00 44 00 00 >> /bye > > Disclaimer: I?ve never actually tried that, but that?s what I would do > in such a case after reading the specs. I guess that with a ?permanently > blocked? card, one does not have much to lose? I have, and it works fine (if "fine" is defined as "completely erasing the card and starting from factory-fresh settings") on version 2 cards. Version 1 cards will be bricked according to [1]. I use the strategy outlined at [1]: 1. Add the following lines to a text file called "reset.txt", omitting the equals signs: ====== /hex scd serialno scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 e6 00 00 scd apdu 00 44 00 00 /echo card has been reset to factory defaults ===== 2. Insert the smartcard to be reset. 3. Run "gpg-connect-agent < reset.txt" 4. Remove the smartcard. 5. Wait a few seconds, then reinsert the smartcard. 6. Run "gpg --card-status": the card should show as factory fresh[2]. Cheers! -Pete [1] http://lists.gnupg.org/pipermail/gnupg-users/2009-September/037414.html [2] Fresh scent of pine is optional. -- Pete Stephenson From johanw at vulcan.xs4all.nl Mon Nov 17 20:25:26 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 17 Nov 2014 20:25:26 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> Message-ID: <546A4BA6.9060008@vulcan.xs4all.nl> On 17-11-2014 17:10, Matthias Mansfeld wrote: > But sorry, I disagree a little bit. If we want literally to jam the > secret service's attempts to decrypt mails, then it makes sense to use > encryption for every single mail, private, business, nonsense and spam.... Makes spam filtering a lot harder. But if everyone on the list had to give a public key when signing up that would be possible. Perhaps it would give issues when someone can't get GnuPG to work and is asking for help. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From jays at panix.com Mon Nov 17 21:01:53 2014 From: jays at panix.com (Jay Sulzberger) Date: Mon, 17 Nov 2014 15:01:53 -0500 (EST) Subject: Update In-Reply-To: <546A3508.4010604@gbenet.com> References: <546A3508.4010604@gbenet.com> Message-ID: On Mon, 17 Nov 2014, david at gbenet.com wrote: > Having spent many many days on this problem I have failed to come with any working solution. > Running a 64 bit version of LUbuntu does not work. This is a real fact of life no matter > what all you people say. It does not work for me. I have tried Fedora-16 64 bit in the past > - it failed - I tried Suse-14 64 bit in the past and it too failed. And now LUbuntu 64 bit > fails too. > > My only option is to install a 32 bit Linux O/S and a 64 bit laptop. Or wipe the partition > and give it all to Windoz. > > Thank you for putting up with my ravings and my frustrations and I thank the very very small > band of people that offered practical help. All I do know is: > > (1) When I remove gnupg2 from Enigmail all but one problem goes away. > (2) Then up stuck with "bad passphrase" without even entering the passphrase. > (3) 32 bit Linux works fine for me > (4) 64 bit Linux does not work for me. > > For those of you that can not accept reality see a psychiatrist. > > David Have you sat down, in front of one or more of the computers at issue here, with a friend who is experienced and willing to help? If not you have not begun the serious task of debugging. You have a stack of stuff, which is fragile in the traditional way, and from your reports to this list, it is difficult to tell where the problem might lie. I do have two pieces of finite advice: 1. Do not re-install your OS. Re-installing will just introduce further difficulties which have, almost surely, nothing to do with your original problem. 2. Attempt to get GnuPG its own self setup right, without involving Enigmail, GNUIPGFront22.6, or Filbert-Kong-Crypto-Manager. Use only the command line. oo--JS. From rjh at sixdemonbag.org Mon Nov 17 21:21:13 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 17 Nov 2014 15:21:13 -0500 Subject: Update In-Reply-To: References: <546A3508.4010604@gbenet.com> Message-ID: <546A58B9.6010508@sixdemonbag.org> On 11/17/2014 3:01 PM, Jay Sulzberger wrote: > > [a lot of stuff with no quote-editing] > Please, guys. Werner has asked for us to trim our quotes, not to just quote the other person's email in full. Let's do that, okay? From nan at goodcrypto.com Mon Nov 17 21:30:32 2014 From: nan at goodcrypto.com (Nan) Date: Mon, 17 Nov 2014 20:30:32 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <20141117203032W58cCrjZNE@goodcrypto.com> Hi Robert, >This would have the ultimate effect of destroying email as a platform. . . antispam . . . malware I think you'll find this has been solved for years. The solution is PGP/etc. between mail servers, and TLS/SSL to the user. Solutions like GoodCrypto integrate with your existing mail server. Your antispam and antivirus work as always. The sysadmin simply configures the mail server to filter inbound mail for viruses, spam, etc. after it's been decrypted. End users don't have to change how they read/write email nor use any special plugins. TLS/SSL to their mail client keeps messages private within the group. >no really effective client-side antispam measures Right. That's the sysadmin's job. An additional advantage of having MTA to MTA encryption is that many organizations need a record of all mail messages. Sometimes it's required by law. User-to-user encryption makes that record unreadable. This solution doesn't block experts who prefer user-to-user encryption, but an organization may object for the reasons that you gave, Robert. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From dkg at fifthhorseman.net Mon Nov 17 22:31:24 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Nov 2014 11:31:24 -1000 Subject: Receiving keys as root user In-Reply-To: <546A17E6.5040302@archlinux.org> References: <546A17E6.5040302@archlinux.org> Message-ID: <546A692C.3010504@fifthhorseman.net> On 11/17/2014 05:44 AM, Allan McRae wrote: > I have a GPG keychain for the root user which is used to validate all > files in my package management system. To add a key into this key > chain, I have been running: > > sudo gpg --homedir /etc/pacman.d/gnupg/ --recv-keys EAE999BD > > With the 2.1 release, this now give the following error: > > gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC connect > call failed > gpg: keyserver receive failed: No dirmngr > > > Is there a way to handle this that I am missing or is it a bug? what version of dirmngr are you running? gnupg 2.1.0 needs to use dirmngr 2.1.0 (found in the gnupg 2.1.x source now, instead of the separate distribution). btw, i strongly recommend against using short Key IDs as desscribed above ("--recv-keys EAE999BD") -- these are trivial to spoof, and using them as you do above makes it quite likely that you'll pull in keys from the keyservers that you do not want in your package manager's trusted list. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Nov 17 23:38:15 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 17 Nov 2014 17:38:15 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141117203032W58cCrjZNE@goodcrypto.com> References: <20141117203032W58cCrjZNE@goodcrypto.com> Message-ID: <546A78D7.1060807@sixdemonbag.org> > I think you'll find this has been solved for years. The solution is > PGP/etc. between mail servers, and TLS/SSL to the user. Given that I've seen PGP-signed spam mails, no, I think you're being naive. > Solutions like GoodCrypto integrate with your existing mail server. Then I don't want it. If you're running the mailserver and you can decrypt my secured messages, then there's nothing preventing the federal government from serving you with a subpoena saying, "please hand over the encryption keys." The only person who can be trusted to do the decryption is the end user, running on hardware the end user directly controls. > This solution doesn't block experts who prefer user-to-user > encryption, but an organization may object for the reasons that you > gave, Robert. I care very little about what happens to corporations. You're still talking about destroying the antispam experience of end-users. That's what I have the biggest problem with. From galex-713 at galex-713.eu Mon Nov 17 23:13:06 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Mon, 17 Nov 2014 23:13:06 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546A431D.1060607@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 17 Nov 2014 13:49:01 -0500") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A431D.1060607@sixdemonbag.org> Message-ID: <87a93ppjbh.fsf@galex-713.eu> On 2014-11-17 at 19:49, Robert J. Hansen wrote: >> Most of the technical reasons can be bypassed by making a single >> subscriber key (public and private) available as a part of the >> subscription process, but that eliminates most of the technical >> advantages of encryption, so it's really a moot point. > > It also means there's pretty much no point in keeping archives, > because it's inevitable that the keys will become separated from the > archives. And if the key is part of the archive, then what's the > purpose of the crypto in the first place? > > Once, for my job, I had to look into the way the Roman Senate > conducted its elections. I was able to find ballots that were over > 1500 years old. It was pretty neat, and it changed my perspective on > things like crypto. > > The crypto dream is that the confidentiality of our messages will be > preserved for centuries after our death, Well, no. The crypto dream is that powerful people will stop being able to retrieve lot of informations on why they exerce power on, and that these people will be able to inform and communicate in a decentralized, horizontal and autonomous manner wathever this autority wants. > which sounds really great up until you consider what an archaeologist > circa 4000 AD is going to be thinking. "I have a stack of records > here that could shed light on the way people lived in a long-dead > civilization, but I can't read them. Why? What were these people > doing that they thought their email to their Aunt Edna needed to > remain secret for all time? Why is it that, millennia after they're > gone, Aunt Edna's recipe for potato salad has to be gone with them?" Then the question is not ?Do we want to encrypt everything??, but more precisely: ?do we want to make everything *accessible*?. Actually imagine mail servers today, quite all encrypting everything with TLS. Not a problem, mails are still accessible. It just means it?s harder for ISPs (MITM is visible, and being visible means a great risk) to spy on people. If we make only some traffic encrypted they have at least the information of what is enough important to be hidden, when, where, by who, to who, for how long, etc. meta-data. Here we make cryptoanarchy and hide everything so that they don?t even have the information of what is to hide. But that doesn?t obligate us to make what is public public. We could imagine a web where everybody uses HTTPS: pages are still accessible to everybody. We could imagine bittorrent where almost all clients encrypt everything (hint: it?s already this way), and everything is still accessible. We could imagine Tor Hidden Services, and everything is still accessible. What?s not accessible anymore is metadata. > Or think about your own kids, circa 2040 AD. "I'd love to read these > emails between Mom and Dad when they were courting, but ... they were > afraid of Somebody-with-an-S reading their emails. I wonder if they > ever thought that the Somebody might be their son, who wanted to > understand after their deaths how it was these two people came to meet > and fall in love." Then comes the problem of private messages, made to be private. First, future archeology is pointless argument between our security and our freedom, it sounds a lot more better like kind of an excuse. Second, a reccurent problem in cryptography is we know computers power and algorithms constantly evolves, and that what?s encrypted a way today is not guaranted to always be forever. What?s encrypted with DSA today will maybe be accessible within more time. Finally, information generally needs to be private only for a limited amount of times. If we have a message describing date and place for a dissidents reunion in a totalitarian state, once the reunion is over, the message doesn?t need to be private anymore, and could be ?released?, if it?s for archival/archeology/history needs. Actually it would be something quite interesting for people to know in what kind of place reunions are planned (anyway a place should never be the same twice). > Historians called the early medieval period "the Dark Ages" not > because the era was full of villainy and evil, but because > record-keeping became so austere that we really don't know much of > what happened for that period. Because they had no efficient way to keep information in front of the quantity of information producible. The press solved this problem. > We're living in a new Dark Age right now. Historians of the future > are going to see human record-keeping basically end around 1960. They?re still accessible. And what?s saying you in the future all hard-disk will die at the same moment with no backup? It could be plausible if our civilization could break down just like others before and let others develop. The problem is: today we have a world-wide civilization, if this one break down, there will be no more civilization to study us. So we have absolutely no reasons to care. > Fewer records were printed out and more were put on digital media -- > media that deteriorates much more quickly than paper, and depends on > technology to read it, technologies which become obsolete and are > discarded even faster than the media degrades. I doubt a paper newspaper can subsist more time than a hard disk. > So when you hear people advocate "crypto everywhere, always, for > everything," ask yourself this: if they get what they want, what will > it do to future generations' ability to make sense of our time? Can you explain in what future generations? curiosity is more important than this generation?s freedom? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From free10pro at gmail.com Tue Nov 18 00:06:52 2014 From: free10pro at gmail.com (Paul R. Ramer) Date: Mon, 17 Nov 2014 15:06:52 -0800 Subject: Nearly fixed In-Reply-To: <1993197.P7LUBvh86f@forge> References: <54679335.1030100@gbenet.com> <1993197.P7LUBvh86f@forge> Message-ID: <60597095-A90F-4AE8-AC4F-BD234A03FF86@gmail.com> On November 15, 2014 10:02:44 AM PST, Samir Nassar wrote: >For those of you who come to David's post in the future through the >mailing >list archive: Disregard this misconception. Many of us, myself >included, use >gpg2 on a 64bit system without a problem. Personally, I have used gpg2 and gpg on 64-bit and 32-bit versions of Linux, Macintosh, and Windows. It has always been transparent. No issues to write home about. Cheers, -Paul -- PGP: 3DB6D884 From allan at archlinux.org Tue Nov 18 00:08:56 2014 From: allan at archlinux.org (Allan McRae) Date: Tue, 18 Nov 2014 09:08:56 +1000 Subject: Receiving keys as root user In-Reply-To: <546A692C.3010504@fifthhorseman.net> References: <546A17E6.5040302@archlinux.org> <546A692C.3010504@fifthhorseman.net> Message-ID: <546A8008.7010604@archlinux.org> On 18/11/14 07:31, Daniel Kahn Gillmor wrote: > On 11/17/2014 05:44 AM, Allan McRae wrote: >> I have a GPG keychain for the root user which is used to validate all >> files in my package management system. To add a key into this key >> chain, I have been running: >> >> sudo gpg --homedir /etc/pacman.d/gnupg/ --recv-keys EAE999BD >> >> With the 2.1 release, this now give the following error: >> >> gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC connect >> call failed >> gpg: keyserver receive failed: No dirmngr >> >> >> Is there a way to handle this that I am missing or is it a bug? > > what version of dirmngr are you running? gnupg 2.1.0 needs to use > dirmngr 2.1.0 (found in the gnupg 2.1.x source now, instead of the > separate distribution). I am using the latest version: # dirmngr --version dirmngr (GnuPG) 2.1.0 > btw, i strongly recommend against using short Key IDs as desscribed > above ("--recv-keys EAE999BD") -- these are trivial to spoof, and using > them as you do above makes it quite likely that you'll pull in keys from > the keyservers that you do not want in your package manager's trusted list. Sure. That was just for an example. Allan From rjh at sixdemonbag.org Tue Nov 18 00:11:39 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 17 Nov 2014 18:11:39 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <87a93ppjbh.fsf@galex-713.eu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A431D.1060607@sixdemonbag.org> <87a93ppjbh.fsf@galex-713.eu> Message-ID: <546A80AB.80303@sixdemonbag.org> > Well, no. The crypto dream is that powerful people will stop being > able to retrieve lot of informations on why they exerce power on, and > that these people will be able to inform and communicate in a > decentralized, horizontal and autonomous manner wathever this > autority wants. Oh, please. If I take you seriously then I'm only concerned about people with power who wish to exert power over me. Nonsense. I'm concerned about *it's nobody's business but mine*. I don't need to subscribe to power-relations theory in order to believe privacy is a good idea; I just need to believe some things are nobody's business but mine. > First, future archeology is pointless argument between our security > and our freedom, it sounds a lot more better like kind of an excuse. I don't know what you're trying to say here. > Second, a reccurent problem in cryptography is we know computers > power and algorithms constantly evolves, and that what?s encrypted a > way today is not guaranted to always be forever. What?s encrypted > with DSA today will maybe be accessible within more time. We also know, quite precisely, the thermodynamic limits of computation. Power evolves, but is easy to account for. Mathematical understanding is harder to predict. > Because they had no efficient way to keep information in front of > the quantity of information producible. The press solved this > problem. No, the printing press didn't solve the problem. Gutenberg invented the printing press in the 15th century, but we've got *great* records going back to the 11th century. And we've also got great records going back to ancient Egypt. It's only a few centuries after the collapse of Rome that are lost to history. They weren't lost for technological reasons: they were lost for human ones. > They?re still accessible. And what?s saying you in the future all > hard-disk will die at the same moment with no backup? Many magnetic tapes from the Viking program (a 1976 effort to put a probe on Mars) were put in storage for later processing. Around 2010, NASA finally got around to processing these tapes... only to discover the machines to read it no longer existed, no one knew what data format it was written in, and not one single person associated with the Viking program was still at NASA. Many of them were dead. It took an enormous amount of resources to reverse-engineer the format, rebuild/rehabilitate old tape machines, and pull the data off. If the data had been less important than "this is stuff we pulled from *MARS*", the entire thing would've been written off as a sad case of knowledge being lost to the ages. In 1086, William the Conqueror ordered the whole of England be surveyed and every plot of land described. That text, the Domesday Book, is still around today. In 1986, to celebrate the 900th anniversary of the Domesday Book, the BBC put together a neat little computer package that was a modern updating of Domesday. Good luck finding it today, though. The UK National Museum of Computing in Milton Keynes is the only place I know of that still has working BBC-Domesday hardware. There have been a couple of attempts to take this project and salvage the data and programs, but so far it's been a big case of not enough money and not enough skilled volunteers. Some of it has been salvaged, but as a whole... no, and it's probably going to be lost to us. Every MLS/MLIS I know is having anxiety attacks over the subject of digital decay. This is a *huge* problem, and it's only getting worse. > I doubt a paper newspaper can subsist more time than a hard disk. Walk into your local library sometime and ask to see their newspaper collection. You might be surprised. My local library has newspapers going back over a century. > Can you explain in what future generations? curiosity is more > important than this generation?s freedom? This is just the fallacy of the zero-sum game, so I'm not even going to bother with it. I did not say, "we should not ensure the privacy of our records." I said, "we should consider what we are giving up when we demand eternal privacy." From galex-713 at galex-713.eu Mon Nov 17 22:58:34 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Mon, 17 Nov 2014 22:58:34 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546A2A0F.3020704@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 17 Nov 2014 12:02:07 -0500") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> Message-ID: <87egt1pjzp.fsf@galex-713.eu> On 2014-11-17 at 18:02, Robert J. Hansen wrote: >> But sorry, I disagree a little bit. If we want literally to jam the >> secret service's attempts to decrypt mails, then it makes sense to use >> encryption for every single mail, private, business, nonsense and spam.... > > This would have the ultimate effect of destroying email as a > platform. Email works as well as it does -- as well as fails so > miserably in other ways -- largely *because* it's open to inspection. Because today it works the way it works is not a reason to let it work that way forever whatever is context. > As an example, pervasive end-to-end encryption would require antispam > defenses to move to the client rather than being deployed at the > mailserver or relay. This would essentially be tantamount to giving > up, since there are no really effective client-side antispam measures. Internet is fundamentally superior to all other technic networks invented by mankind for this reason: moving intelligence to periphery, make work client-side, make things horizontal, decentralized everything, giving control on everything to everybody locally, making everybody able to do anything wathever others do. That?s what distinguish Internet from what existed in France before Internet?: the minitel. The minitel is a dumb terminal only able to connect via phone-lines to a server, send input to server and display what server send back. It were popular when computers where too much expensive and nobody could have one. In the free software and decentralized/secure internet movement in France, we generally use the term ?Minitel 2.0? to humorously speak about (and mock) GAFA and all ultra-centralized services where quite everything tends to be made server-side, where the client is just a dumb terminal controlling nothing and delegating everything to the server. Where the server can do anything. rms also denounced SaaSS as worse evil than proprietary software, and that?s true. Because with just proprietary software you can still cut the Internet (or even just its access to it), and even do reverse-engineering. With SaaSS, URSS and 1984 seem a happy pink poney world. The fact is that doing everything client-side, you can adapt everything even better than Google would do, because *you* control it. You could use spamassasin-like rules based on naive bayes filtering, and choose yourself what you identify as a spam, then choose to make a message more visible or not according its probability to be it. Then you could even make more category than just ?vacation/viagra/enlarge-penises-like spam?, you could try to do the same thing about insulting messages, (death/rape)menaces messages, racist, sexist, homophobic, transphobic nationalist, classists messages (all containing some interesting common patterns, and it could even be useful on some mailing-lists, more practical than just banning people, could just prevent people to read messages that they could consider psychologically hurtful to them, while letting other trying to deal with some people?s annoying ideas). If that can work, you could even share score lists in a F2F manner, and ponder that according bonds, and then secure everything with cryptographic signature, and identify people with DHTs, etc. etc. Decentralizing you can do quite everything, and very very very very interesting things. Then with just complex maths, moderns DHT, etc. you can achieve quite spectacular things, avoiding issues like ?Facebook has a considerable part of mankind population subscribed, is able to statistically determine if someone is homosexual even without him/her knowing it, and activally collaborate with especially intolerant authoritarian governments or agencies, especially if payed well? (yellow star seems pointless in front of that). Give a look to what GNUnet tries to do. > Similarly, it would assist in the spread of malware and viruses and > for the same reasons. If a mailserver can't inspect the email, it > can't recognize malware and quarantine it for the health of the > internet. Malware and viruses is the problem of client, only client, always client. If we have to make a less freedom-compatible internet because of client not doing its job, there?s a problem. As far as I know that especially regards proprietary systems. > Etc., etc. I am fanatically in favor of people's right to protect the > privacy of their communications, but there's a flipside to it: we also > need to be responsible and prudent with how we do it. Simple, naive > solutions like "encrypt everything!" aren't a fix: at best, they'll > trade our current set of problems for a new set of problems which > we'll have even less knowledge of how to handle. So instead of trying to make nice authorities known for their authoritarian interests and with a creepy background, you?ll try to just invent, and most of time just implement, new algorithms? One of these solutions seems more realist to me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From allan at archlinux.org Tue Nov 18 04:44:23 2014 From: allan at archlinux.org (Allan McRae) Date: Tue, 18 Nov 2014 13:44:23 +1000 Subject: Receiving keys as root user In-Reply-To: <546A8008.7010604@archlinux.org> References: <546A17E6.5040302@archlinux.org> <546A692C.3010504@fifthhorseman.net> <546A8008.7010604@archlinux.org> Message-ID: <546AC097.4040608@archlinux.org> On 18/11/14 09:08, Allan McRae wrote: > On 18/11/14 07:31, Daniel Kahn Gillmor wrote: >> On 11/17/2014 05:44 AM, Allan McRae wrote: >>> I have a GPG keychain for the root user which is used to validate all >>> files in my package management system. To add a key into this key >>> chain, I have been running: >>> >>> sudo gpg --homedir /etc/pacman.d/gnupg/ --recv-keys EAE999BD >>> >>> With the 2.1 release, this now give the following error: >>> >>> gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: IPC connect >>> call failed >>> gpg: keyserver receive failed: No dirmngr >>> >>> >>> Is there a way to handle this that I am missing or is it a bug? >> >> what version of dirmngr are you running? gnupg 2.1.0 needs to use >> dirmngr 2.1.0 (found in the gnupg 2.1.x source now, instead of the >> separate distribution). > > I am using the latest version: > > # dirmngr --version > dirmngr (GnuPG) 2.1.0 > I have found running "dirmngr < /dev/null" as root creates /root/.gnupg/S.dirmngr and allows gpg to work properly. Is this something that should happen automatically? Allan From david at gbenet.com Tue Nov 18 09:36:33 2014 From: david at gbenet.com (david at gbenet.com) Date: Tue, 18 Nov 2014 08:36:33 +0000 Subject: Nearly fixed In-Reply-To: <60597095-A90F-4AE8-AC4F-BD234A03FF86@gmail.com> References: <54679335.1030100@gbenet.com> <1993197.P7LUBvh86f@forge> <60597095-A90F-4AE8-AC4F-BD234A03FF86@gmail.com> Message-ID: <546B0511.4080603@gbenet.com> On 17/11/14 23:06, Paul R. Ramer wrote: > On November 15, 2014 10:02:44 AM PST, Samir Nassar wrote: >> For those of you who come to David's post in the future through the >> mailing >> list archive: Disregard this misconception. Many of us, myself >> included, use >> gpg2 on a 64bit system without a problem. > > Personally, I have used gpg2 and gpg on 64-bit and 32-bit versions of Linux, Macintosh, and Windows. It has always been transparent. No issues to write home about. > > Cheers, > > -Paul > > > > -- > PGP: 3DB6D884 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Paul, Just because you have no problems - and then to take on the role of an authority is misguided - and i must say completely stupid of you. Everything's all right with my world and so everything's right in the world - all other people's wrongs are fictions. Your remarks are entirely your own - and have no basis in the real world. The more you write the more fictions you will produce. (1) I accept without any questions that people run Linux and Windoz 64 bit and have no problems - I accept this as a reality. (2) Another reality which I accept is that running a Linux 64 bit O/S you can not sign or encrypt files. (3) Another reality I have to accept is none or very very very few of you have the technical know-how to come up with a solution. (4) I'd not ask most of you to change a light-bulb. But I still like you :) David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From nan at goodcrypto.com Tue Nov 18 10:43:54 2014 From: nan at goodcrypto.com (Nan) Date: Tue, 18 Nov 2014 09:43:54 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <201411180943541ky8YN2nJo@goodcrypto.com> Hi Robert, > Given that I've seen PGP-signed spam mails, no, I think you're being naive. You use the same antispam/antivirus you use now. What people do today is a little complex, so I understand why it's not clear: your mail server -> your crypto server (decrypts) -> your mail server (antispam etc) -> user (tls) > If you're running the mailserver and you can decrypt my secured messages, then there's > nothing preventing the federal government from serving you with a subpoena saying, > "please hand over the encryption keys." I agree. A third party should never handle the filtering of mail. If my email is nan at mygroup.org, then mygroup.org handles the encryption, decryption, spam filtering, etc. > The only person who can be trusted to do the decryption is the end user, > running on hardware the end user directly controls. In an ideal world, yes. But after 20 years of recommending user-to-user encryption, it's clear most users can't or won't. As Bruce Schneier says, "If there's anything PGP has taught us, it's that one click is one click too many." Experts can still encrypt any messages they want individually. We can't leave the rest of us unprotected. > I care very little about what happens to corporations. I agree again. I'm much more concerned about human rights groups and stopping mass surveillance. > You're still talking about destroying the antispam experience of end-users. The group's mail server handles spam, viruses, etc., just like it does today. No change for the user. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From dgouttegattat at incenp.org Tue Nov 18 11:18:17 2014 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 18 Nov 2014 11:18:17 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141117203032W58cCrjZNE@goodcrypto.com> References: <20141117203032W58cCrjZNE@goodcrypto.com> Message-ID: <546B1CE9.8090900@incenp.org> On 11/17/2014 09:30 PM, Nan wrote: > I think you'll find this has been solved for years. The solution is PGP/etc. between mail servers, and TLS/SSL to the user. Why use PGP between mail servers? SSL/TLS can be used for that, too. Actually, opportunistic server-to-server TLS is supported by many mail server software, and is becoming more and common. Using PGP for anything less than end-to-end encryption seems pointless to me. Particularly if it distracts mail server administrators from enabling server-to-server TLS, which we need anyway to protect the metadata (headers) that are *not* encrypted by PGP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Nov 18 11:23:01 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Nov 2014 11:23:01 +0100 Subject: Update In-Reply-To: (Jay Sulzberger's message of "Mon, 17 Nov 2014 15:01:53 -0500 (EST)") References: <546A3508.4010604@gbenet.com> Message-ID: <87ioicq03e.fsf@vigenere.g10code.de> On Mon, 17 Nov 2014 21:01, jays at panix.com said: > Have you sat down, in front of one or more of the computers at > issue here, with a friend who is experienced and willing to help? That is what I was about to suggest - having a second pair of eyeballs looking at a problem very often solves a problem in a few seconds. @all: Please save our all time and do not reply here to David's mails until that has happened. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tux.tsndcb at free.fr Tue Nov 18 10:14:32 2014 From: tux.tsndcb at free.fr (tux.tsndcb at free.fr) Date: Tue, 18 Nov 2014 10:14:32 +0100 (CET) Subject: card is permanently locked! In-Reply-To: Message-ID: <1309919855.3509890.1416302072535.JavaMail.root@zimbra33-e6.priv.proxad.net> Hello, I can confirm, works fine. Best Regards ----- Mail original ----- De: "Pete Stephenson" ?: "Damien Goutte-Gattat" Cc: "GnuPG Users Mailing List" Envoy?: Lundi 17 Novembre 2014 20:15:09 Objet: Re: card is permanently locked! ====== /hex scd serialno scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 scd apdu 00 e6 00 00 scd apdu 00 44 00 00 /echo card has been reset to factory defaults ===== 2. Insert the smartcard to be reset. 3. Run "gpg-connect-agent < reset.txt" 4. Remove the smartcard. 5. Wait a few seconds, then reinsert the smartcard. 6. Run "gpg --card-status": the card should show as factory fresh[2]. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From mailing-lists at asatiifm.net Tue Nov 18 11:57:20 2014 From: mailing-lists at asatiifm.net (=?iso-8859-1?Q?Ville_M=E4=E4tt=E4?=) Date: Tue, 18 Nov 2014 12:57:20 +0200 Subject: Encryption on Mailing lists sensless? In-Reply-To: <201411180943541ky8YN2nJo@goodcrypto.com> References: <201411180943541ky8YN2nJo@goodcrypto.com> Message-ID: <2F440976-FF44-4C1E-AA71-120120E73B0A@asatiifm.net> UX-designer-aproach to car design: "We need to remove break and clutch pedals from cars because our user studies say that a 3 pedal interface for driving an automobile is just way too difficult." I say those who can?t be arsed to learn how, do not deserve a driver?s license. You let a child fail and try again until they learn? so on and so forth. Some encryption software UI is too difficult, yes, some pretty much lack a UI. Fair enough. But the "one click is one click too many? defeatist mentality is just wrong. It is not always the UI?s fault and sometimes you just have to say ?make the user learn or make ?em go away?. Yes, it?s a valid option. PS: I work with UI and UX folks on software all the time. Yes, it might get a little heated sometimes :). -- Ville On 18 Nov 2014, at 11:43, Nan wrote: > In an ideal world, yes. But after 20 years of recommending user-to-user encryption, it's clear most users can't or won't. As Bruce Schneier says, "If there's anything PGP has taught us, it's that one click is one click too many." Experts can still encrypt any messages they want individually. We can't leave the rest of us unprotected. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: Message signed with OpenPGP using GPGMail URL: From galex-713 at galex-713.eu Tue Nov 18 15:27:23 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Tue, 18 Nov 2014 15:27:23 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <201411180943541ky8YN2nJo@goodcrypto.com> (nan@goodcrypto.com's message of "Tue, 18 Nov 2014 09:43:54 GMT") References: <201411180943541ky8YN2nJo@goodcrypto.com> Message-ID: <87y4r8mvn8.fsf@galex-713.eu> On 2014-11-18 at 10:43, Nan wrote: >> If you're running the mailserver and you can decrypt my secured messages, then there's >> nothing preventing the federal government from serving you with a subpoena saying, >> "please hand over the encryption keys." > > I agree. A third party should never handle the filtering of mail. If > my email is nan at mygroup.org, then mygroup.org handles the encryption, > decryption, spam filtering, etc. mygroup.org is a third party. mygroup.org is static. mygroup.org is a different person than nan. mygroup.org can be corrupted, menaced or cracked. nan will not know. >> The only person who can be trusted to do the decryption is the end user, >> running on hardware the end user directly controls. > > In an ideal world, yes. But after 20 years of recommending > user-to-user encryption, it's clear most users can't or won't. Context changes. 20 years ago fascism weren?t raising again at this rate, petrol wasn?t at a decade of ending, and Snowden didn?t made his revelations. It doesn?t mean it?s impossible but it means we were doing it wrong. The GNUnet philosophy of ?just prepare the change of roughly everything, make all the simplest possible and do a lot of philosophical/political education? seems the most utopic, but also the more realist to me. > As Bruce Schneier says, "If there's anything PGP has taught us, it's > that one click is one click too many." Experts can still encrypt any > messages they want individually. We can't leave the rest of us > unprotected. Within MUA such as ClawsMail, Thunderbird, etc. you don?t need a click, just a configuration. Within networks such as GNUnet you don?t need a configuration, just a ?registration?, ?connection?, ?installation?, or wathever you call it. Your adress is your public key, on computer it can be the nick associated in a signed entry within DHT possibly with a vizhash, and physically it?s a QRCode. Nothing more simple. It?s actually simpler that the current unencrypted internet. And as it were said, to gain freedom sometimes you need an effort. If you consider it pointless, you deserve to remain a slave. >> I care very little about what happens to corporations. > > I agree again. I'm much more concerned about human rights groups and stopping mass surveillance. Making authority nice? Teaching people freedom is not utopic, making authority nice and respectful is. >> You're still talking about destroying the antispam experience of end-users. > > The group's mail server handles spam, viruses, etc., just like it does today. No change for the user. Yes, no. any. change. Unfortunately. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From rjh at sixdemonbag.org Tue Nov 18 16:11:41 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Nov 2014 10:11:41 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <201411180943541ky8YN2nJo@goodcrypto.com> References: <201411180943541ky8YN2nJo@goodcrypto.com> Message-ID: <546B61AD.8080409@sixdemonbag.org> > I agree. A third party should never handle the filtering of mail. If > my email is nan at mygroup.org, then mygroup.org handles the > encryption, decryption, spam filtering, etc. A third party -- your mailserver administrator -- should never handle the decryption or signing. (There may be a couple of use cases where it makes sense, but they're few and far between.) All it takes is a subpoena, and any citizen can file one of those. It appears that you're selling a "solution" that involves giving a third party access to your plaintext, all the while telling people that your product will keep their communications secure. I don't see how that can be called anything other than snake oil. > I agree again. I'm much more concerned about human rights groups and > stopping mass surveillance. So far you've -- * Made false claims that DSA is compromised * Made false claims that NIST only minimally changed a compromised standard * Advocated giving third-parties regular and routine access to plaintext None of this is compatible with your claim that you're concerned about human rights groups and stopping mass surveillance. Please stop hyping snake oil. From mwood at IUPUI.Edu Tue Nov 18 16:14:29 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 18 Nov 2014 10:14:29 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546A2A0F.3020704@sixdemonbag.org> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> Message-ID: <20141118151429.GA917@IUPUI.Edu> It's time to expose my ignorance again, hopefully to cure some of it. On Mon, Nov 17, 2014 at 12:02:07PM -0500, Robert J. Hansen wrote: > > But sorry, I disagree a little bit. If we want literally to jam the > > secret service's attempts to decrypt mails, then it makes sense to use > > encryption for every single mail, private, business, nonsense and spam.... > > This would have the ultimate effect of destroying email as a platform. > Email works as well as it does -- as well as fails so miserably in other > ways -- largely *because* it's open to inspection. > > As an example, pervasive end-to-end encryption would require antispam > defenses to move to the client rather than being deployed at the > mailserver or relay. This would essentially be tantamount to giving up, > since there are no really effective client-side antispam measures. Would this not at the same time make it simple for MUAs to discover that "this message is not from anyone you say you know. Delete without reading?" Because to decrypt the SPAM, you need the public key, which is identifiable. Even if the spammers lie, well, it's from no one you know, or it's verifiably *not* from who the sender claims to be. > Similarly, it would assist in the spread of malware and viruses and for > the same reasons. If a mailserver can't inspect the email, it can't > recognize malware and quarantine it for the health of the internet. Again, if it's provably from no one you say that you trust, the MUA could refuse to execute runnable content without explicit permission. (Which I say should be the normal and only setting for all content, but I know I'm a crank.) I can also say that, so far as I know, the principal effect of MTA-based antivirus in my life is to prevent me consciously emailing known innocuous code that I wrote to people who ask for it. So I for one wouldn't miss it. That's selfish of me, of course. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From nan at goodcrypto.com Tue Nov 18 16:34:33 2014 From: nan at goodcrypto.com (Nan) Date: Tue, 18 Nov 2014 15:34:33 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <20141118153433iRAs2nqp44@goodcrypto.com> Alexandre, do you really believe that anyone could "deserve to remain a slave"? Assuming you don't, I'll address your calmer points. > mygroup.org can be corrupted, menaced or cracked. Sure, a server is a single point of failure for the group, and must be carefully configured and protected. It's still much safer than hoping users will protect themselves. > the change of roughly everything I prefer solutions that protect as many people as possible now. > ClawsMail, Thunderbird, etc. People usually don't want to change mail clients. Most have no idea how to configure crypto or manage keys. Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From rjh at sixdemonbag.org Tue Nov 18 17:09:05 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Nov 2014 11:09:05 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118151429.GA917@IUPUI.Edu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> Message-ID: <546B6F21.2050705@sixdemonbag.org> > Would this not at the same time make it simple for MUAs to discover > that "this message is not from anyone you say you know. Delete > without reading?" Sure, but that also destroys the email ecosystem. One of email's strongest points has been that no introduction is necessary to begin a conversation. This year I found myself re-engaging with a friend I lost touch with a decade ago, who found me on a mailing list and figured to drop an email and see if maybe I was the same Rob Hansen she knew from back when. If my MUA/MTA had hidden it from me just because there was no introduction, or urged me to delete it without reading... Could email as a platform survive the shift to introduction-based systems? Sure. But it would totally transform the email experience, and maybe in ways we wouldn't like. That's why I'm so skeptical of proposals to fix email in this way: we might fix email, but we might also kill it at the same time. > Again, if it's provably from no one you say that you trust, the MUA > could refuse to execute runnable content without explicit > permission. (Which I say should be the normal and only setting for > all content, but I know I'm a crank.) It already is. Double-click on an executable attachment and a window will pop up with a warning about how you should only run code from people you know and trust, click "OK" to cancel running this, click "I know the risks" to run it, etc. An awful lot of people click "I know the risks." I've told this story before, but it bears repeating -- During my grad school days I had a colleague named Peter Likarish. Peter did some great work in using Bayesian statistics to detect phishing sites. Ultimately, he had an algorithm that could look at webpage content and decide with 95% accuracy whether it was real or phish-phood. He packaged this up inside a Firefox extension: when you browsed to a site and the plugin detected a phishing attempt, it would put a narrow red stripe over the top of the screen saying, "Warning: this may be a phishing attempt!" He put it into human trials using the University's HCI (Human-Computer Interactions) lab. The results were dismal. Post-experience interviews revealed that people weren't looking at the top of the web page. They genuinely didn't notice a red stripe across the top of the screen. So Peter went back to the drawing board and made a new interface. Now, the banner started off small, but there was a "Click to dismiss" button on it. Further, the banner would grow larger over time. Peter knew that the human eye is sensitive to motion: our eyes naturally are drawn to things that change. By making the banner grow larger, he figured he could increase its visibility. Back to the lab, and ... still dismal, soul-crushing results. This time, the overwhelming majority of the users confirmed they saw the warning. When Peter asked them why they chose to ignore it, the majority said they thought it was just another Flash ad that was hyping some "fix your PC fast, now!" solution. I ran into Peter shortly after he finished his final day of human trials. He was normally a very cheerful guy, but this day he just looked shattered. I suggested we walk down to the nearest watering hole and grab a beer, but he was too dejected. He said that of all the outcomes he imagined for his Ph.D., he never dreamed that it would be that his research could be accurately summed up as, "the technology works fine, it's *people* who are completely broken." Shortly after I left grad school Peter found a warning mechanism that worked, incidentally. It's a cute technology and one I really wish more browsers would incorporate. I don't have a URL for a PDF of the paper handy, but the poster he presented at SOUPS 2009 is available online at: https://cups.cs.cmu.edu/soups/2009/posters/p9-likarish.pdf From nan at goodcrypto.com Tue Nov 18 18:30:33 2014 From: nan at goodcrypto.com (Nan) Date: Tue, 18 Nov 2014 17:30:33 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <20141118173033xCi55Ehu8G@goodcrypto.com> > third party -- your mailserver administrator The "third party" you don't trust is your own sysadmin. That person already has access to the plain text messages right now. So does everyone tapping your connections. We suggest that you limit that risk to the sysadmin you already trust. > telling people that your product will keep their communications secure Yes, we are. We suggest that GPG crypto is more secure than no crypto, and better when it works for everyone in the group. Experts can still encrypt their own messages. That approach has had 20 years to work. Most people still don't encrypt mail at all. Good encryption that is used is much better than encryption only used by an elite. > Made false claims that DSA is compromised I said "was certainly compromised in the past". As you know, one source for DSA flaws is the current ssh-keygen man page: "DSA keys must be exactly 1024 bits as specified by FIPS 186-2." You apparently feel there is some explanation for "exactly 1024 bits" other than the obvious one, that keys of that length are compromised. NIST changed this spec later, but always kept DSA. If you want another source, NSA themselves consider DSA, specifically ECDSA, to be only Grade B security. With their usual misdirection, NSA calls it "Suite B". Red Hat explicitly says the NSA's Suite B is only good enough for "most" classified information. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.5_Release_Notes/bh-chap-security.html > Made false claims that NIST . . . NIST has often changed specs as each compromise is discovered. Examples are DES, DSA, and Elliptic Curve. A very recent discussion is from "Keeping Secrets -- STANFORD magazine" (https://medium.com/stanford-select/keeping-secrets-84a7697bf89f): "The agency has a second tactic to prevent the spread of cryptographic techniques: keeping high-grade cryptography out of the national standards. To make it easier for different commercial computer systems to interoperate, the National Bureau of Standards (now called NIST) coordinates a semipublic process to design standard cryptographic algorithms. ... The NSA's influence over the standards process has been particularly effective at mitigating what it perceived as the risks of nongovernmental cryptography. By keeping certain cryptosystems out of the NBS/NIST standards, the NSA facilitated its mission of eavesdropping on communications traffic." I suggest you are more careful about your accuracy before you make accusations of false claims, or use the nasty slur "snake oil". GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From mirimir at riseup.net Tue Nov 18 19:15:57 2014 From: mirimir at riseup.net (Mirimir) Date: Tue, 18 Nov 2014 11:15:57 -0700 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118173033xCi55Ehu8G@goodcrypto.com> References: <20141118173033xCi55Ehu8G@goodcrypto.com> Message-ID: <546B8CDD.5010700@riseup.net> What distinguishes a mail list from email with bcc? Software? Size? As long as messages were separately encrypted to each recipient, no third parties would be involved. From kristian.fiskerstrand at sumptuouscapital.com Tue Nov 18 18:51:38 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 18 Nov 2014 18:51:38 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118173033xCi55Ehu8G@goodcrypto.com> References: <20141118173033xCi55Ehu8G@goodcrypto.com> Message-ID: <546B872A.8040706@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/18/2014 06:30 PM, Nan wrote: >> third party -- your mailserver administrator > > The "third party" you don't trust is your own sysadmin. That > person already has access to the plain text messages right now. So > does everyone tapping your connections. We suggest that you limit > that risk to the sysadmin you already trust. > Any chance you can fix your client's handling of threading? You seem to start a new top post on every reply. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Potius sero quam numquam Better late then never -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUa4cjAAoJEPw7F94F4TagNc4QAJ4tRHvHD/AmjG9ye1W1+3oS IjRAzDgz+VKLYZzbVN7qmQzq3GzHIHZ3VIBOQPqurpSRdBl8R5ICB1cLTsgjBRhN dsBid2KGRm7pRw/XmEmgmr0SQxppAJSeGWVNCqvSyfqmZ2gjN9pUYO8em8KhtpJP Bz/k74ZgToQFodQrCuo8hooa+zgcC1J//juexu+GRWv36HF1tI3ynyuraDnS9smD oEkEPqrAQCKdoonyfLv+R+XHaL0Rww95whCmXtfiFfZMZNJUl8LQBmDEJHiCe4YD ZWIW+mcV6L9QQ7VRvRl+zg654OLb/QqWFkMhrkT4luKBbiJ4GphtET8Ivfvin5U5 uenQBUR9WHCQIxR+Nq2zf5TPW4MUlh60Up5ejnzCqLIOSD1DUwW2/JfisVHLLK+a lQggVWUNqph0p+atT4zrbU+KsfR+j818C31x4D0XR/1OvXs7dXNF27Q4UUSm0k9s GwuIX++wX5+/3nplxOK8SC3adY2BT3MfBxwfgMHNz1+wPiw752zC6WHAuZ9xdcZ3 u/kGJewMfkcsOoqILsO8iqOPYgziqUuhvEIyc8msWALAdrIe6p/zVZEXOhQVzkM1 mMm8FAAsIjac1wc/NM/6I9ZGfAxBlb4RDusDDtDLuntBbRiHn0E75Qm6bl73drTI qZaVgdst11SNc2CtgxUy =65X0 -----END PGP SIGNATURE----- From nan at goodcrypto.com Tue Nov 18 19:30:48 2014 From: nan at goodcrypto.com (Nan) Date: Tue, 18 Nov 2014 18:30:48 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <20141118183048JjhDI9s78l@goodcrypto.com> Thanks, Kristian. I will look into it. GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From mwood at IUPUI.Edu Tue Nov 18 19:47:52 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 18 Nov 2014 13:47:52 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546A431D.1060607@sixdemonbag.org> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A431D.1060607@sixdemonbag.org> Message-ID: <20141118184752.GB917@IUPUI.Edu> On Mon, Nov 17, 2014 at 01:49:01PM -0500, Robert J. Hansen wrote: [snip] > The crypto dream is that the confidentiality of our messages will be > preserved for centuries after our death, which sounds really great up > until you consider what an archaeologist circa 4000 AD is going to be > thinking. "I have a stack of records here that could shed light on the > way people lived in a long-dead civilization, but I can't read them. > Why? What were these people doing that they thought their email to > their Aunt Edna needed to remain secret for all time? Why is it that, > millennia after they're gone, Aunt Edna's recipe for potato salad has to > be gone with them?" > > Or think about your own kids, circa 2040 AD. "I'd love to read these > emails between Mom and Dad when they were courting, but ... they were > afraid of Somebody-with-an-S reading their emails. I wonder if they > ever thought that the Somebody might be their son, who wanted to > understand after their deaths how it was these two people came to meet > and fall in love." This raises an interesting point. If I bequeath my collected letters to someone, how do I arrange the transmission of the necessary passphrases as well? I wonder if the lawyer who draws up my will would even understand the question. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From m.mansfeld at mansfeld-elektronik.de Tue Nov 18 20:07:38 2014 From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld) Date: Tue, 18 Nov 2014 20:07:38 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118184752.GB917@IUPUI.Edu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A431D.1060607@sixdemonbag.org> <20141118184752.GB917@IUPUI.Edu> Message-ID: <20141118200738.Horde.4s_LoLgijAC3fNDP3C5fsw1@webmail.df.eu> Zitat von "Mark H. Wood" : [...] > This raises an interesting point. If I bequeath my collected letters > to someone, how do I arrange the transmission of the necessary > passphrases as well? I wonder if the lawyer who draws up my will > would even understand the question. If we want to leave our stuff to the archeologists, we can store our own mails unencrypted. So do I (just because it is easier for me AND because I can keep my computers - hopefully - safe with other measures). If we want to jam the sniffers from the secret services,(I wrote about this motivastion in the very beginning of this discussion!) then it is totally enough just to encrypt the mails end to end on their way. Regards Matthias -- Matthias Mansfeld Elektronik * Leiterplattenlayout Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8 Internet: http://www.mansfeld-elektronik.de GPG http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc From galex-713 at galex-713.eu Tue Nov 18 20:07:31 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Tue, 18 Nov 2014 20:07:31 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118153433iRAs2nqp44@goodcrypto.com> (nan@goodcrypto.com's message of "Tue, 18 Nov 2014 15:34:33 GMT") References: <20141118153433iRAs2nqp44@goodcrypto.com> Message-ID: <87k32smioc.fsf@galex-713.eu> On 2014-11-18 16:34, Nan wrote: > Alexandre, do you really believe that anyone could "deserve to remain a slave"? In the meaning ?it?s normal/understandable/explainable to be a slave if you want freedom without doing nothing to get it while other want you not to be?, yes. But all the importance of the meaning is in the ?if? part. I think if someone do nothing, or do anything anyway, it?s for a reason, or, to be more precise, a cause, and I call this reason deserving freedom itself an initial lack of freedom (of thought, if you want). So for me, actually, ?deserving? doesn?t exist, doesn?t have any true real meaning, just as ?merit?, ?duty?, ?pride?, ?shame? (in their meaning, not their objective existence as a sentiment) or ?free will? (in its meaning opposed to determinism). > Assuming you don't, I'll address your calmer points. > >> mygroup.org can be corrupted, menaced or cracked. > > Sure, a server is a single point of failure for the group, and must be > carefully configured and protected. From the point this server isn?t you, it?s never ?protected? enough. You could maybe protect *enough* (and only *enough*, never ?perfectly?). And that?s just about ?cracking?, which is just a technical concern, not the more important. Because menace and corruption still exist. You could say you trust your provider? which is already really really really hard? is your provider independent from thing such as money? corruption? power? And even if it were, arguing that nodaways anybody could resist to currently existing powers and authorities is a fallacy. > It's still much safer than hoping users will protect themselves. Not ?hoping they will?, making so they will, because it?s the only way to deal with. As I said everybody learned to read and it?s more complicated than basic crypto usage. As I said systems rebuilt from scratch upon these ideas can be much simpler than everything existing before. And with context changing, need will come, and people, when they need it, can adopt something really quickly, at least as fast as they can. >> the change of roughly everything > > I prefer solutions that protect as many people as possible now. I didn?t say all of that were incompatible ;) They?re short-term as long-term solutions to things that need to change. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From galex-713 at galex-713.eu Tue Nov 18 20:09:01 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Tue, 18 Nov 2014 20:09:01 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118153433iRAs2nqp44@goodcrypto.com> (nan@goodcrypto.com's message of "Tue, 18 Nov 2014 15:34:33 GMT") References: <20141118153433iRAs2nqp44@goodcrypto.com> Message-ID: <87fvdgmilu.fsf@galex-713.eu> >> ClawsMail, Thunderbird, etc. > > People usually don't want to change mail clients. Most have no idea > how to configure crypto or manage keys. They?re just the default and almost more used MUA. If you exclude proprietary software and SaaSS (webmail). But asking for privacy using proprietary services is a fallacy. I mean, you can?t say ?PGP/GNUnet/other-crypto-implementation is useless to protect users, they use webmails? and say we fix the problem wrong. Because there is *no way* they can get true privacy with only a webmail. It would be ridiculous. When I said ?deserve?, I said that you can?t expect freedom when you?re putting on you your strings yourself. PS: sorry for the two mails, I got confused. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From ndk.clanbo at gmail.com Tue Nov 18 20:21:08 2014 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 18 Nov 2014 20:21:08 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546B8CDD.5010700@riseup.net> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> Message-ID: <546B9C24.50409@gmail.com> Il 18/11/2014 19:15, Mirimir ha scritto: > What distinguishes a mail list from email with bcc? Software? Size? That you're sending to a *single* address that hides the others. > As long as messages were separately encrypted to each recipient, no > third parties would be involved. But: 1) you should disclose the whole list of subscribed addresses (that's really valuable metadata -- not to say a dream for spammers!) 2) you make mail headers and message size "explode" Not good, IMVHO... BYtE, Diego. From rjh at sixdemonbag.org Tue Nov 18 20:34:57 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Nov 2014 14:34:57 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141118173033xCi55Ehu8G@goodcrypto.com> References: <20141118173033xCi55Ehu8G@goodcrypto.com> Message-ID: <546B9F61.6010209@sixdemonbag.org> > The "third party" you don't trust is your own sysadmin. That person > already has access to the plain text messages right now. So does > everyone tapping your connections. We suggest that you limit that > risk to the sysadmin you already trust. You're introducing a single point of failure -- and a SPOF that's highly susceptible to coercion, at that. You say you're opposed to widespread surveillance: this does *nothing* to address that. The only people it will stop are the people who aren't smart enough to realize, "You know, I could just get a subpoena." Or the ones who think, "You know, I could just plant malware on the sysadmin's computer and gain access to all their encrypted communications at once." Or the ones who think... I think that's exceptionally foolish. Build systems that provide a measure of security against smart, dedicated attackers -- don't build systems that only provide it against childish ones. This is not a solution. This is a surrender. >> Made false claims that DSA is compromised > > I said "was certainly compromised in the past". As you know, one > source for DSA flaws is the current ssh-keygen man page: > > "DSA keys must be exactly 1024 bits as specified by FIPS 186-2." > > You apparently feel there is some explanation for "exactly 1024 bits" > other than the obvious one, that keys of that length are compromised. You have not presented *any* evidence that 1024-bit keys are compromised. For that matter, you haven't presented any evidence that you understand what a FIPS is. A FIPS is a *Federal* Information Processing Standard. It's not binding on private citizens. All FIPS 186-x says is, "if you want to use digital signatures with the United States Government, here is the digital signature scheme that we use." FIPS specifies a standard for the USG to use, not one for private citizens to use. Is it really so strange that a standards document would specify parameters for an algorithm? For that matter, DSA has never been limited to any keysize, not even under the FIPS 186-2 regime. DSA is the Elgamal signature scheme with a very slight algorithmic tweak to reduce one avenue of attack on it. If a private citizen likes DSA but thinks it would be better with a 8192-bit key, they're free to go for it. It's just Elgamal, after all. We know how to extend DSA arbitrarily. We just don't, because there's really no point in it. FIPS 186-2, which you're obsessing about, was released in January of 2000. In January of 2000, 1024-bit keys were expected to be safe for the next 20 years. There has never been *any* credible hint that, in January of 2000, the belief was that Elgamal signature schemes of length 1024 bits were suspect. It was the standard signature scheme in use in GnuPG 1.0 and PGP 6.5.8, both of which date back to that era. Find me a single peer-reviewed paper published in a reputable journal that says DSA-1024 is compromised. (Joe Bob's Web Page of Crypto doesn't count. Something like EUROCRYPT or Financial Cryptography does.) One. Just *one*. Do that and I'll happily eat a whole steaming plate of crow, feathers and all. But until then, I believe you're a dangerous charlatan. > If you want another source, NSA themselves consider DSA, specifically > ECDSA, to be only Grade B security. With their usual misdirection, > NSA calls it "Suite B". False. See, e.g.: https://www.nsa.gov/IA/Programs/suiteb_cryptography/ Browse around there and you'll find Suite B is certified for TS/SCI information. Again: this is publicly available information that the authors want to be shared as broadly as possible. > Red Hat explicitly says the NSA's Suite B is > only good enough for "most" classified information. False. Let's quote the exact page, shall we? "[Suite B] serves as an interoperable cryptographic base for both unclassified information and most classified information." It never says it's only good enough for most classified information. It says it's used as an interoperable cryptographic base for most classified information. Given the size of the USG, it wouldn't surprise me if there was a rotor machine still in use somewhere. There's a lot of inertia there: bureaucracies don't change overnight, and the entire USG didn't switch to Suite B the moment the spec was published. >> Made false claims that NIST . . . > > NIST has often changed specs as each compromise is discovered. > Examples are DES... With respect to DES, false. DES was proposed to the National Bureau of Standards (NIST's predecessor) in 1976; it was published as a FIPS in 1977, and was subjected to periodic five-year reviews in '83, '88, '93 and '99. No compromise has ever been discovered in DES; as of today, the best known method for breaking DES is brute force. > DSA... You have not presented evidence for a single compromise against DSA. You point to a FIPS parameter specification and say "the only reason this would happen is if it was compromised!", yet the civilian cryptographic community -- which has looked at DSA *very* closely -- disagrees emphatically. > and Elliptic Curve. Dual_EC_DRBG was handled in an appropriate manner: NIST advised against its usage and then completely withdrew it from the standard. > I suggest you are more careful about your accuracy before you make > accusations of false claims, or use the nasty slur "snake oil". I've been quite careful, and I believe you're hawking snake oil. From jays at panix.com Tue Nov 18 20:37:17 2014 From: jays at panix.com (Jay Sulzberger) Date: Tue, 18 Nov 2014 14:37:17 -0500 (EST) Subject: Update In-Reply-To: <87ioicq03e.fsf@vigenere.g10code.de> References: <546A3508.4010604@gbenet.com> <87ioicq03e.fsf@vigenere.g10code.de> Message-ID: On Tue, 18 Nov 2014, Werner Koch wrote: > On Mon, 17 Nov 2014 21:01, jays at panix.com said: > >> Have you sat down, in front of one or more of the computers at >> issue here, with a friend who is experienced and willing to help? > > That is what I was about to suggest - having a second pair of eyeballs > looking at a problem very often solves a problem in a few seconds. > > @all: Please save our all time and do not reply here to David's mails > until that has happened. > > > Shalom-Salam, > > Werner Thanks, Werner! For this note and for all. oo--JS. From 2014-667rhzu3dc-lists-groups at riseup.net Tue Nov 18 23:43:18 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 18 Nov 2014 22:43:18 +0000 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546B8CDD.5010700@riseup.net> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> Message-ID: <448302142.20141118224318@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 18 November 2014 at 6:15:57 PM, in , Mirimir wrote: > As long as messages were separately encrypted to each > recipient, no third parties would be involved. For an email message with multiple recipients, I think most mail clients and OpenPGP encryption agents that I have looked at encrypt the message to all addressees at once. I only recall one combination that encrypted an individual copy for each addressee, and am not sure I correctly remember which it was. And for mailing lists, Schleuder [0] encrypts the outgouing list messages to each recipient. The only third party involved is the list server, whic always exists on a discussion list. [0] - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The One with The Answer is seldom asked The Question -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRry5VXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pTJAEALZmeHPXUO7Gx9iWWHmviHoZ3sPkfLd3SPnl llOvQkQB252LSZ4wIli1pg0VLDLX5NdNAN/ur+8c7BFxNMLq0n+5KHrHs15U87C6 yZ3QgYCUo0/bY0gLG4bDyWGqOWYk7STJNSIfxNosrnGb/baxIRkjUrNe7xfuDTmT IiNiUxHkiQF8BAEBCgBmBQJUa8uVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw/6MH/1JdX9qrmDa3x793 P2q9ZhCfkgjUnhdutGyilcU+ic0PmdP092vJiVIZW/ekXCwWx749u90idkEHa9lP rwRNU1i/ASYTmV8CojKOyS8sABCwvgRbaPSvjC8fd126YwfVxbQ9kR2L3aHg2qHy z3RnoLTEF0XjNkSdYXDF85eDVnis233RxrgB73nAcMIa0Mw2uh1vAv4QuP3qzqJM sish4Ulie+VzldQh4WjHy+XG0XxxU5Tt3bCMNWHOiJo4XVmYgRLvsgefNkOTdFH5 /FkzDS85cTHykuOHNc2ZIeCggnie9nwtq3VfFrIN2O5EG2EsO3MdnMkomI3rJEug VNEcX4I= =daFX -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Wed Nov 19 00:08:05 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 18 Nov 2014 23:08:05 +0000 Subject: Error message "Ohhhh jeeee: ... this is a bug" In-Reply-To: <87ppcmqcyq.fsf@vigenere.g10code.de> References: <629851038.20141115194527@my_localhost> <87ppcmqcyq.fsf@vigenere.g10code.de> Message-ID: <1417552682.20141118230805@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 17 November 2014 at 11:32:45 AM, in , Werner Koch wrote: > Can you produce a test case using sample keys? So far I have only managed to reproduce it using the keys I already have. I will try again over the next few days. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net It's better to feed one cat than many mice -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRr0VpXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5po9wD/30zDVZQaQ017QM0cLXgNpyIOmcioGaTryiz 0vs61KJjsp4t/8wiC5zyspi+eym+Jf/74xgOs9DH4jJ5NySo7vBG52wTGxeGpNxp cBcvDWSZ6vnWiloD7v02AcSD+GkN/duabcztMHwir5cP3M9xbEYSnxXlaBO25IZ6 BhSw4EbyiQF8BAEBCgBmBQJUa9FaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwLS8H/1tpFFnpyLHNbUZl A73tyqG7Y84WMMCMOG4wK1CJEDdj7vdbRjtFl1otCZXZbRrkpLFgY7lFZWHqkCRI sPgX2AYSGN36u8n7b4cWPYK/7BH867/3jogIbFVAnGVxPJuH1okvth9/oyJn99B7 1Vf/jMWatISoutk7ODaC5da0VLryngvUayPnvpOwRh2ALA2h1iD4S/7PUFg/ZfYt ei4NTrstN10a7SsxhIqk7EhH5YxvSAVflMlya3Ef5E3ETxTMMYGZpM/9ivv5Pbuv yE4ZJZLHN75S5vDvDPAmF2HFEIdit/iTOP0Iz0AH7c+LhtZ/xDYoiZkl/lqU+Q+u A2NvT2w= =wnoY -----END PGP SIGNATURE----- From mirimir at riseup.net Wed Nov 19 00:11:03 2014 From: mirimir at riseup.net (Mirimir) Date: Tue, 18 Nov 2014 16:11:03 -0700 Subject: Encryption on Mailing lists sensless? In-Reply-To: <448302142.20141118224318@my_localhost> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> <448302142.20141118224318@my_localhost> Message-ID: <546BD207.8070606@riseup.net> On 11/18/2014 03:43 PM, MFPA wrote: > Hi > > > On Tuesday 18 November 2014 at 6:15:57 PM, in > , Mirimir wrote: > > >> As long as messages were separately encrypted to each >> recipient, no third parties would be involved. > > For an email message with multiple recipients, I think most mail > clients and OpenPGP encryption agents that I have looked at encrypt > the message to all addressees at once. I only recall one combination > that encrypted an individual copy for each addressee, and am not sure > I correctly remember which it was. Right, it would be necessary to do it manually, or script it. > And for mailing lists, Schleuder [0] encrypts the outgouing list > messages to each recipient. The only third party involved is the list > server, whic always exists on a discussion list. As I read that, recipients need to trust the list server's reports about senders' signatures. I'd rather decrypt and verify signatures myself, and not trust the list server ultimately. > [0] From mirimir at riseup.net Wed Nov 19 00:18:50 2014 From: mirimir at riseup.net (Mirimir) Date: Tue, 18 Nov 2014 16:18:50 -0700 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546B9C24.50409@gmail.com> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> <546B9C24.50409@gmail.com> Message-ID: <546BD3DA.6090404@riseup.net> On 11/18/2014 12:21 PM, NdK wrote: > Il 18/11/2014 19:15, Mirimir ha scritto: > >> What distinguishes a mail list from email with bcc? Software? Size? > That you're sending to a *single* address that hides the others. As soon as a recipient replies, their address is no longer hidden. >> As long as messages were separately encrypted to each recipient, no >> third parties would be involved. > But: > 1) you should disclose the whole list of subscribed addresses (that's > really valuable metadata -- not to say a dream for spammers!) Sorry, I wasn't clear. By saying bcc, I meant that each outgoing message would have just one recipient address. > 2) you make mail headers and message size "explode" > > Not good, IMVHO... I'm not sure that I understand this point. > BYtE, > Diego. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From galex-713 at galex-713.eu Wed Nov 19 00:42:11 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Wed, 19 Nov 2014 00:42:11 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546B6F21.2050705@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 18 Nov 2014 11:09:05 -0500") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> Message-ID: <87y4r8kre4.fsf@galex-713.eu> On 2014-11-18 at 17:09, Robert J. Hansen wrote: >> Would this not at the same time make it simple for MUAs to discover >> that "this message is not from anyone you say you know. Delete >> without reading?" > > Sure, but that also destroys the email ecosystem. One of email's > strongest points has been that no introduction is necessary to begin a > conversation. This year I found myself re-engaging with a friend I lost > touch with a decade ago, who found me on a mailing list and figured to > drop an email and see if maybe I was the same Rob Hansen she knew from > back when. If my MUA/MTA had hidden it from me just because there was > no introduction, or urged me to delete it without reading... > > Could email as a platform survive the shift to introduction-based > systems? Sure. But it would totally transform the email experience, > and maybe in ways we wouldn't like. That's why I'm so skeptical of > proposals to fix email in this way: we might fix email, but we might > also kill it at the same time. It?s completely true. However Mark?s right when saying it could help to do it client-side: client-side, you can access *all* private (meta)data on user without any privacy problem, and use it to better detect what?s a spam, and actually that would be really useful (isn?t it really easy for you personally, who know yourself, to detect if something is a spam or a message really adressed to you?). As he said, contacts are useful. So yes, roughly filtering spam from not-yet-introduced friends lacks flexibility and destroy several email nice features. But we can do thiner: lower the score given with bayesian autostabilizating equations. >> Again, if it's provably from no one you say that you trust, the MUA >> could refuse to execute runnable content without explicit >> permission. (Which I say should be the normal and only setting for >> all content, but I know I'm a crank.) > > It already is. Double-click on an executable attachment and a window > will pop up with a warning about how you should only run code from > people you know and trust, click "OK" to cancel running this, click "I > know the risks" to run it, etc. > > An awful lot of people click "I know the risks." A longer text explaining ?you giving this program the authorization to do what it wants with your data and configuration, including destroying, corrupting, stealing, spying, reveling anything?. But the true solution is this one: use only free software, software you?re sure you can check the sources. Even more: having build information, sources and binary signed cryptographically. Even more: being sure this binary is made with reproducible builds. Even more: everything of that available trough a censorship-resistant P2P filesharing system. > He said that of all the outcomes he imagined for his Ph.D., he never > dreamed that it would be that his research could be accurately summed > up as, "the technology works fine, it's *people* who are completely > broken." Yeah, we need interdisciplinarism: a great part of work to change the world, added to technical progress, is education. It?s maybe *the* biggest and most important thing. Sometimes you don?t need to adapt to the society but adapt the society to you and people: ?The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.? ? George Bernard Shaw -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Nov 19 01:31:55 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 18 Nov 2014 19:31:55 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <87y4r8kre4.fsf@galex-713.eu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> Message-ID: <546BE4FB.9080903@sixdemonbag.org> > It?s completely true. However Mark?s right when saying it could help > to do it client-side... No. Client-side, you get to inspect (fully) only your data, and you have to develop a statistical model of spam based on only your data. When Gmail filters, it inspects (fully) traffic to *millions* of users, and uses that to create a model no individual user can hope to match. Encrypting everything, even Aunt Edna's recipe for potato salad, means a significant step backwards in the spam fight. I love decentralized algorithms, but there's something to be said for a God's-eye perspective on the problem -- look at decentralized route discovery protocols versus Dijkstra's algorithm as an example. > But the true solution is this one: use only free software, software > you?re sure you can check the sources. Maybe one user in ten thousand has the skill to audit a nontrivial codebase. Free software is a good idea, but let's not pretend that normal users will realize a real benefit from being able to check their source code. From galex-713 at galex-713.eu Wed Nov 19 07:24:58 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Wed, 19 Nov 2014 07:24:58 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546BE4FB.9080903@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 18 Nov 2014 19:31:55 -0500") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> <546BE4FB.9080903@sixdemonbag.org> Message-ID: <87ppcjlnb9.fsf@galex-713.eu> Le 19/11/2014 ? 01h31, Robert J. Hansen a ?crit?: >> It?s completely true. However Mark?s right when saying it could help >> to do it client-side... > > No. Client-side, you get to inspect (fully) only your data, and you > have to develop a statistical model of spam based on only your data. > When Gmail filters, it inspects (fully) traffic to *millions* of users, > and uses that to create a model no individual user can hope to match. You can do some stats on multiple persons using hashes, meshes, propagation and this kind of thing. Even better: you can do it F2F, and ponderate according distance in number of hops. See what try to do GNUnet. That?s way better than large, politically risky and impersonal large Google scans. > Encrypting everything, even Aunt Edna's recipe for potato salad, means a > significant step backwards in the spam fight. I love decentralized > algorithms, but there's something to be said for a God's-eye perspective > on the problem -- look at decentralized route discovery protocols versus > Dijkstra's algorithm as an example. We have to make some sacrifices to get freedom. So yes it can and will be more complex to stop centralize. But it especially involves an other thinking model: not a big centralistic individual one, but a *collective* one, where you think ?I have a thousand instance, how should each of these act so that the whole networks work respecting both Order and Anarchy??. It?s a lot more complex, but also a lot more interesting, and potentially a lot more powerful. >> But the true solution is this one: use only free software, software >> you?re sure you can check the sources. > > Maybe one user in ten thousand has the skill to audit a nontrivial > codebase. Free software is a good idea, but let's not pretend that > normal users will realize a real benefit from being able to check their > source code. One in ten thousand is enough. And anyway: that was the case too about written language some centuries ago. How could that not change? For instance a way greatest amount of Emacs users know several parts of its code source, and are able to inspect any part at any moment if needed. And the real benefit is in the *freedom to*, which has only to be express by the ability to do something, even if ??everybody?? doesn?t know how, a sparse minority is enough. That?s the concept of free software. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From nan at goodcrypto.com Wed Nov 19 09:54:01 2014 From: nan at goodcrypto.com (Nan) Date: Wed, 19 Nov 2014 08:54:01 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <20141119085401WpNdUuCja0@goodcrypto.com> Robert, let's try to defuse this. To quote Werner, Salam-Shalom. First, "charlatan" and "snake oil" imply deceit. Goodcrypto: * Is open source * Uses GPG for mail encryption * Links to "The limits of GoodCrypto" right on the front page * Has asked for audits from many people, including: * Open Crypto Audit Project * EFF * Privacy International I humbly suggest this demonstrates that we are trying very hard not to fool anyone. You made the great point that a mail server and sysadmin is a single point of failure. This is covered in our Design document referenced from our Technical FAQ. There are tradeoffs to everything. Because a mail crypto server is a tempting target, we have to protect it very carefully. Please let us know the details about any successful attacks you find. We'll have to disagree on whether we should ignore clear evidence about DSA because academics haven't published yet. I understand this is very important to you because of your NIST association. I'll try hard to let you have the last word :) Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From peter at digitalbrains.com Wed Nov 19 12:17:19 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 19 Nov 2014 12:17:19 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546BE4FB.9080903@sixdemonbag.org> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> <546BE4FB.9080903@sixdemonbag.org> Message-ID: <546C7C3F.4070903@digitalbrains.com> On 19/11/14 01:31, Robert J. Hansen wrote: > No. Client-side, you get to inspect (fully) only your data, and you > have to develop a statistical model of spam based on only your data. > When Gmail filters, it inspects (fully) traffic to *millions* of users, > and uses that to create a model no individual user can hope to match. I agree with several other important points you raise, but this one is not a big deal. I have a highly customized mail setup. My SpamAssassin downloads rules from the internet, but trains its Bayesian filter on only the e-mail I personally receive. Everyone who has ever sent me a non-spam mail is added to a whitelist. Mail from whitelisted people never gets automatically moved to the Spam box, and my mail client shows their messages in a different color. As soon as I receive a spam mail from such an address, it is immediately (manually) deleted from the whitelist (actually moved to the greylist so it's not added to the whitelist again next time). I have an empty blacklist. It exists, though. It would cause mail to be silently deleted. Somebody once had the honour of having me create it and put him on it :). SpamAssassin throws spams in a Spam folder for me to check every few weeks. I sort them by subject line so I can quickly scan through. Checked spam that I perceived as spam is still kept around for quite a while, just in case someone writes to me "I wrote you months ago and you haven't replied". Then I can go back to everything I've already written off as spam to see if I looked past their mail. This setup works great for me. If I get a few false positives in a year, it is a lot. They are so scarce that I'm completely unsure what the actual number is. I do get false negatives, but it doesn't feel like more than 10 each week. Every now and then a short surge of nearly identical spams, though.[1] I still think your overall point stands, and stands tall. But the spam filtering issue; from personal experience, I don't think that's a really major issue. If it were, I'm sure we can think of some way to have publicly available training data that can be refined by individuals who can feed it back to the publicly available data. It might need some thought: you don't want to have a really classified mail which got qualified as spam to upload new words to the public data. So probably most individuals would only adjust existing weights, and only some setups would contribute new words. This could come from spamtraps and organisations or even individuals who send in complete training mails. And perhaps this all is even not necessary, and the system would be just as effective with a big corpus of data where only weights are changed by submissions. But this is all a bit beside the point. The point is that spam filtering works just fine on an individual level, for me. And if it would create problems, I'm sure we can think of things that would solve that specific issue. Peter. PS: By the way, some mail is already denied at the mailserver and never enters the system. The most important instance of this is mail purporting to come from myself, but not originating from within my own network. Lots of spammers send you spams from your own address, be it in the envelope or in the headers. I run my own webmail server, so even if I need to send myself a message and I didn't bring my laptop, it would still originate from my own webmail server. [1] Actually that is a case where the distributed solution truely excels: quickly homing in on the latest mass mailing. The sheer number of identical mails alone is a big warning sign, and a lot of people will start reporting them as spam. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Nov 19 12:28:04 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 19 Nov 2014 12:28:04 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141119085401WpNdUuCja0@goodcrypto.com> References: <20141119085401WpNdUuCja0@goodcrypto.com> Message-ID: <546C7EC4.4040403@digitalbrains.com> On 19/11/14 09:54, Nan wrote: > First, "charlatan" and "snake oil" imply deceit. They often do, don't they? I doubt that is what is meant, though. If I look in the Oxford online dictionary: Definition of charlatan in English: noun A person falsely claiming to have a special knowledge or skill Definition of snake oil in English: noun [mass noun] informal , chiefly North American 1 A substance with no real medicinal value sold as a remedy for all diseases 1.1 A product, policy, etc. of little real worth or value that is promoted as the solution to a problem These all seem to definitely be how I interpreted Rob's messages. I personally never read any implication of wilfull deceit, but I'm famous for missing nastiness sometimes.[1] I can completely understand you read an implication of wilfull deceit. I doubt it is actually there, though. Does this help in defusing? > We'll have to disagree on whether we should ignore clear evidence about DSA > because academics haven't published yet. I understand this is very important > to you because of your NIST association. I hope you've already defused by now, because this looks like lighting the fuse. Hopefully by now it's just a bit of fizzing wire, kept well away from the bomb. Peter. [1] Okay, in light of a recent event: sometimes I see nastiness that's not there! ;) -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From galex-713 at galex-713.eu Wed Nov 19 12:55:37 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Wed, 19 Nov 2014 12:55:37 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546C7C3F.4070903@digitalbrains.com> (Peter Lebbing's message of "Wed, 19 Nov 2014 12:17:19 +0100") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> <546BE4FB.9080903@sixdemonbag.org> <546C7C3F.4070903@digitalbrains.com> Message-ID: <87mw7nmmkm.fsf@galex-713.eu> Le 19/11/2014 ? 12h17, Peter Lebbing a ?crit?: > On 19/11/14 01:31, Robert J. Hansen wrote: >> No. Client-side, you get to inspect (fully) only your data, and you >> have to develop a statistical model of spam based on only your data. >> When Gmail filters, it inspects (fully) traffic to *millions* of users, >> and uses that to create a model no individual user can hope to match. > > I agree with several other important points you raise, but this one is not a big > deal. I have a highly customized mail setup. My SpamAssassin downloads rules > from the internet, but trains its Bayesian filter on only the e-mail I > personally receive. And you can even share within a F2F meshed system the bayesian-trained rules. For example everybody could send her ?friends? her set of rules, including the one of her friends, dividing the ?credibility? of rules according number of hops they made (with a logarithmic progression). You could even define more categories than just ?looks-like spam (ads)?, but also the same about insults/troll (comparing the number of exclamation marks with the size of message or this kind of details can be useful to gain a *lot* of time), shaming messages, menace messages (so useful if each MUA in the world could automatically filter rape menaces feminist activists receive, for instance, or for any other particulary dangerous/rude activism), racism (?'nigger' = -10 000?, for instance) , LGBTIA-phobia, fascism (?'(natural|objective) differences' = -100?, ?'not like us' = -100?, etc.), etc. And all that could be shared in a point-to-point and F2F manner, so that you?re sure activists of a certain struggle will have their common rules really perfectionned against certain things, and you?ll be sure all that will automatically adapt according people and their milieus, and language/expression evolution (antisemitism, for instance, is not expressed today the same way than yesterday). Oh, and imagine that everything of that could be used not only in email, but in common on every type of asynchronous communication. *Everywhere*. Including blogs/comments, microblogging, mailing-lists (you could even imagine the F2F rules sharing extend to mailing-lists themself so some could contain ?advisory rules? for clients), etc. That would avoid horrible situations like ?transexual people don?t using anymore the Internet to discuss?, ?feminists don?t allowing comments anymore ?loosing a great amount of potential really interesting analysis? and even developping plugins to automatically mask comment systems on blogs?, or ?having someone who?s psychologically hurting a lot of people, wanting a safe space for them but also wanting to have a collaborative space to debate with her to try to fix that and make her able to speak peacefully with others so we can reintegrate her?. Of course good luck if you expect from an authoritarian centralization to become nice and struggle for people rights against the system of inequalities, classes, races or patriarchy? Oh yeah, they /tried/ ?nice centralization to free people? in the East. Didn?t work. Quite the opposite (ostracizing gays and foreigners, forcing women to found families, workers to work, what a success?). However: if you expect freedom from centralization, good luck. > [1] Actually that is a case where the distributed solution truely > excels: quickly homing in on the latest mass mailing. The sheer number > of identical mails alone is a big warning sign, and a lot of people > will start reporting them as spam. And that?s why I spoke about cryptography, and notably about ?hashes?. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From nan at goodcrypto.com Wed Nov 19 13:25:11 2014 From: nan at goodcrypto.com (Nan) Date: Wed, 19 Nov 2014 12:25:11 GMT Subject: Encryption on Mailing lists sensless? Message-ID: <20141119122511J0lVwhoDbq@goodcrypto.com> On 19 Nov 2014 12:28:04 Peter Lebbing wrote: > looks like lighting the fuse *Not* my intent. Just acknowledging that I understand it's important to you, Robert. Feel free to ignore the paragraph. If there's a blast, we'll all survive :) Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From rjh at sixdemonbag.org Wed Nov 19 18:08:42 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 19 Nov 2014 12:08:42 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <20141119085401WpNdUuCja0@goodcrypto.com> References: <20141119085401WpNdUuCja0@goodcrypto.com> Message-ID: <546CCE9A.7040501@sixdemonbag.org> > First, "charlatan" and "snake oil" imply deceit. From Google: "A product, policy, etc. of little real worth or value that is promoted as the solution to a problem." So let me say it clearly: your product is of little real worth or value. It's snake oil. It doesn't appear to bring anything to the table that SMTP+TLS+DNSSEC doesn't already (as M. Garreau already observed before me). > I humbly suggest this demonstrates that we are trying very hard not > to fool anyone. Except the people you want to sell this service to at $5,000 a year. You want them to believe you are a knowledgeable expert about communications and computer security issues. As near as I can tell, you are not, nor do you recognize that you are not. I don't think you're malicious. I think you're foolish and are trying to sell your foolishness to the scared and the desperate at a high price. I am urging, begging, you to stop. It's socially irresponsible. > You made the great point that a mail server and sysadmin is a single > point of failure. This is covered in our Design document referenced > from our Technical FAQ. There is no design document referenced from your technical FAQ. There's an entry, "What is GoodCrypto's design?", that says nothing of your design. It's a marketing document, not something that an engineer can use to get a grip on how the application stack is architected. For that matter, even as marketing material it's rife with errors. "Just reboot to remove Advanced Persistent Threats." If getting rid of it is that simple, it's neither persistent nor advanced. "To avoid forensics, most malware is volatile." Malware, especially poorly-written malware, writes to disk frequently and leaves behind many traces. This is the _raison d'etre_ of the antivirus industry: that's why periodically your AV software scans your hard disk looking for signatures. "Elliptic curve [cryptography] is known [to be] compromised." I would love to see references for this. Again, peer-reviewed papers in reputable journals, please. "Virtual machine attacks are not yet well known." In fact, they're so well known they've broken out of the high-end forensics world and into DEFCON. (Seriously. At DEFCON 20 Alex Minozhenko gave a talk on "How To Hack VMWare In 60 Seconds.") I could go on, but ... I trust my point is made clear. > We'll have to disagree on whether we should ignore clear evidence > about DSA because academics haven't published yet. I've asked for your "clear evidence" several times and the only thing you've got is, "in 2000, NIST specified using 1024-bit keys for DSA. Obviously DSA is compromised." And you haven't even offered that much for your claim that elliptical curve cryptography is compromised. > I understand this is very important to you because of your NIST > association. It's important to me because I despise snake oil, especially when it's sold to desperate and scared people. I am not associated with NIST in any respect other than "I wrote a piece of software for the forensics community which helps facilitate hash lookups against a NIST dataset." Anyway. I'm finished here. I think there's now enough of a record associated with this that when people thinking of dropping $5K on GoodCrypto do a Google search for it, they'll find my objections. From rjh at sixdemonbag.org Wed Nov 19 18:17:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 19 Nov 2014 12:17:26 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546C7C3F.4070903@digitalbrains.com> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> <546BE4FB.9080903@sixdemonbag.org> <546C7C3F.4070903@digitalbrains.com> Message-ID: <546CD0A6.7060704@sixdemonbag.org> > I agree with several other important points you raise, but this one is not a big > deal. I have a highly customized mail setup. My SpamAssassin downloads rules > from the internet, but trains its Bayesian filter on only the e-mail I > personally receive. I don't mean to sound like I'm dismissing your experience, because -- well -- your experience shouldn't be dismissed. (Nobody's should.) But I do think you might be overlooking something: you already experience a significant benefit from the aggressive, God's-eye-view anti-spam efforts of Google, Yahoo!, Microsoft, and more. The things they do for their users have a ripple effect in making your own anti-spam fight a little easier. A couple of months ago Mike Hearn wrote a brilliant treatise on end-to-end cryptography and anti-spam technologies, with a long digression on how anti-spam technologies work at Google. It's worth every second it takes to read. https://moderncrypto.org/mail-archive/messaging/2014/000780.html From hugo.hinterberger at gmx.net Wed Nov 19 18:07:37 2014 From: hugo.hinterberger at gmx.net (Hugo Hinterberger) Date: Wed, 19 Nov 2014 18:07:37 +0100 Subject: Error message "Ohhhh jeeee: ... this is a bug" References: <629851038.20141115194527@my_localhost> <87ppcmqcyq.fsf@vigenere.g10code.de> <1417552682.20141118230805__8083.15750114179$1416352176$gmane$org@my_localhost> Message-ID: Hi, this should go to: "MFPA <2014-667rhzu3dc-lists-groups at riseup.net>", sorry if it goes on the list "gmane.comp.encryption.gpg.user" too (minor user/MUA f-), although this might be interesting to Werner Koch also. I just tried to verify your message, but failed at importing your key. GPG tellst me that the key packet is of an obsolete version 3. Do you have the key in a newer format? Is it possible to import the old key somehow? I attached the console session and public key used. Regards, Hugo On Wed, 19 Nov 2014 00:08:05 +0100, MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Monday 17 November 2014 at 11:32:45 AM, in > , Werner Koch wrote: > > > >> Can you produce a test case using sample keys? > > So far I have only managed to reproduce it using the keys I already > have. I will try again over the next few days. > > > - -- > Best regards > > MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net > > It's better to feed one cat than many mice > -----BEGIN PGP SIGNATURE----- > > iPQEAQEKAF4FAlRr0VpXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl > bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 > N0VDQTAzAAoJEKipC46tDG5po9wD/30zDVZQaQ017QM0cLXgNpyIOmcioGaTryiz > 0vs61KJjsp4t/8wiC5zyspi+eym+Jf/74xgOs9DH4jJ5NySo7vBG52wTGxeGpNxp > cBcvDWSZ6vnWiloD7v02AcSD+GkN/duabcztMHwir5cP3M9xbEYSnxXlaBO25IZ6 > BhSw4EbyiQF8BAEBCgBmBQJUa9FaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp > b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB > NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwLS8H/1tpFFnpyLHNbUZl > A73tyqG7Y84WMMCMOG4wK1CJEDdj7vdbRjtFl1otCZXZbRrkpLFgY7lFZWHqkCRI > sPgX2AYSGN36u8n7b4cWPYK/7BH867/3jogIbFVAnGVxPJuH1okvth9/oyJn99B7 > 1Vf/jMWatISoutk7ODaC5da0VLryngvUayPnvpOwRh2ALA2h1iD4S/7PUFg/ZfYt > ei4NTrstN10a7SsxhIqk7EhH5YxvSAVflMlya3Ef5E3ETxTMMYGZpM/9ivv5Pbuv > yE4ZJZLHN75S5vDvDPAmF2HFEIdit/iTOP0Iz0AH7c+LhtZ/xDYoiZkl/lqU+Q+u > A2NvT2w= > =wnoY > -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xA8A90B8EAD0C6E69.asc Type: application/pgp Size: 932 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMD-GPG-verify-session.txt URL: From galex-713 at galex-713.eu Wed Nov 19 20:31:16 2014 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Wed, 19 Nov 2014 20:31:16 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <546CD0A6.7060704@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 19 Nov 2014 12:17:26 -0500") References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> <546BE4FB.9080903@sixdemonbag.org> <546C7C3F.4070903@digitalbrains.com> <546CD0A6.7060704@sixdemonbag.org> Message-ID: <87egszkmwr.fsf@galex-713.eu> On 2014-11-19 at 18:17, Robert J. Hansen wrote: N>> I agree with several other important points you raise, but this one is not a big >> deal. I have a highly customized mail setup. My SpamAssassin downloads rules >> from the internet, but trains its Bayesian filter on only the e-mail I >> personally receive. > > I don't mean to sound like I'm dismissing your experience, because -- > well -- your experience shouldn't be dismissed. (Nobody's should.) > But I do think you might be overlooking something: you already > experience a significant benefit from the aggressive, God's-eye-view > anti-spam efforts of Google, Yahoo!, Microsoft, and more. The things > they do for their users have a ripple effect in making your own > anti-spam fight a little easier. > > A couple of months ago Mike Hearn wrote a brilliant treatise on > end-to-end cryptography and anti-spam technologies, with a long > digression on how anti-spam technologies work at Google. It's worth > every second it takes to read. > > https://moderncrypto.org/mail-archive/messaging/2014/000780.html He?s mainly explaining how do you fight spam in a centralized way, and then explain how all the centralized techiques are unusable when using crypto. That?s normal, crypto and decentralization comes together. You need to think according other paradigms. It?s like when you live in society. You can either think the autoritarian way ?if I were the Great King Controlling Everything what could I do to fix the problem??, or the social/free way ?what should I do so that if everybody did like me the problem would get fixed??. So that involves way much complex maths (well, actually, *different*: in the centralized world it?s already really complex, but the complexity you need to decentralize is compensated by the local private data you can access and the crypto techniques you become used to), DHTs, meshes, crypto, symmetric communication, political thought, users education, etc. I don?t consider that an issue. Quite the opposite: the result ?and we always end finding it? is *beautifull*. It?s like admiring the almost perfectness of the way human body chemical biology works. It?s like admiring a fractal. You just end with something approaching what you observe within organic structures, something more resilient, perennial, big, free, flexible? Also he speaks about using bitcoin, which is not a good point bitcoin not being really secure: you just need more computational power than the half of the network and you can takeover it. Big government can do it. Also bitcoin needs anyway a lot of computational power, worse, it *encourage* it by competition. That?s really catastrophic ecologically. And finally it suffers from the problem of globalizing everything, contrarily to the Internet (and GNUnet) historical architecture where everything is the most local possible (within the Internet only IP attribution and DNS are global, within GNUnet *nothing* is, so you could transparently divide, join and grow GNUnets without any problem). Yet proof-of-work can be effectively used to prevent abuse. GNUnet use it to prevent spamming its global DHT with lot of revok? certs it will store for a while. It could be made on messages if we didn?t need a certain fastness (merging all asynchronous communication means even microblogging will have the same requirements) and we didn?t already had concepts of mesh, WoT, bayesian filtering, F2F and cryptographic signature. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From MichaelQuigley at TheWay.Org Wed Nov 19 20:50:32 2014 From: MichaelQuigley at TheWay.Org (MichaelQuigley at TheWay.Org) Date: Wed, 19 Nov 2014 14:50:32 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: References: Message-ID: "Gnupg-users" wrote on 11/19/2014 02:30:40 PM: > ----- Message from "Robert J. Hansen" on Wed, > 19 Nov 2014 12:08:42 -0500 ----- > > To: > > Nan , gnupg-users at gnupg.org > > Subject: > > Re: Encryption on Mailing lists sensless? > . . . . . . . . . > Anyway. I'm finished here. I think there's now enough of a record > associated with this that when people thinking of dropping $5K on > GoodCrypto do a Google search for it, they'll find my objections. . . . . . . . . . Which of course would not be possible if the public mailing list was all encrypted. I can't count how many times I find relevant and information that helps with the task on which I'm working by using a search engine. At times, the helpful results are from mailing lists I've never heard of much less subscribed to. Other times the information is on a mailing list I'm familiar with, but don't have the time to follow on a regular basis. I get too much in my inbox as it is. But be able to find the information from a general search engine can be of immense aid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandur at brandur.org Wed Nov 19 07:06:54 2014 From: brandur at brandur.org (Brandur) Date: Tue, 18 Nov 2014 22:06:54 -0800 Subject: Dotfile encryption with GPG Message-ID: <20141119060654.GA83181@bleach-ltm.internal.salesforce.com> Hi gnupg-users, One of the GPG use cases that I'm most interested in is the encryption of some dotfiles which normally reside in my home directory in cleartext, but which contain sensitive credentials. An example of such a file is be `~/.netrc`, a somewhat standardized file that stores web credentials and can be read in by programs such as Curl [1]. One trick to get Curl to read a GPG-encrypted `.netrc` is to pipe it in via stdin as demonstrated here: curl="gpg --batch -q -d $HOME/.netrc.gpg | curl --netrc-file /dev/stdin" This works out pretty well in the case of Curl, but breaks down for more complex programs. For example, if in this case Curl wanted to *write* information back to `.netrc`, this basic approach would no longer be sufficient. One way around this is to start baking GPG support into any program that needs this more sophisticated functionality, but this isn't always possible. Another possible solution is to "wrap" programs with a script that will pass a decrypted file to a program, and optionally re-encrypt the file after the program has exited. I've written a small example of what this might look like that I call "gpgup" here [2]. Going back to our Curl example, it would be used like this: __curl() { GPGUP_PATH=$HOME/.netrc.gpg gpgup 'curl --netrc-file $GPGUP_PATH' $@ } alias curl=__curl A challenge here is that a temporary store must be available that's suitable to temporarily write a decrypted file to, and which would make recovery of the cleartext difficult. I personally write to an encrypted partition which I think is secure enough for *my* purposes. Other possibilities here might be ephemeral stores like a ramdisk just in case a bad exit left a decrypted file behind. My question here is: is there something that I'm missing? Does the standard GPG toolbox include something that would solve this problem more elegantly? If not, would my approach here be considered "good enough"? Thanks for the help! Brandur [1] http://curl.haxx.se/docs/manual.html [2] https://gist.github.com/brandur/a68fb37c4059c281fa6b From web at axalphaconsulting.com Wed Nov 19 09:49:52 2014 From: web at axalphaconsulting.com (web at axalphaconsulting.com) Date: Wed, 19 Nov 2014 09:49:52 +0100 Subject: =?utf-8?Q?SAP=20Partner=20Axalpha=20Consulting=20-=20=C2=BFERP=20?= =?utf-8?Q?Compra=20o=20Alquiler=3F?= Message-ID: <546c59b0c052a@axalphaconsulting6_ip-zone_com-6> SAP Partner Axalpha Consulting - ?ERP Compra o Alquiler? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Newsletter? ? ? SAP Business One: ?ERP Compra o Alquiler? SAP Business One, el ERP que permite que su empresa crezca. Ahora en opci?n de compra o alquiler mensual ? ? Pack PYME Compra - 6 usuarios El ERP dise?ado especialmente para Pymes potente, asequible y escalable. ? Financiaci?n a 12 meses sin intereses 0% ? Inversi?n rentable a corto plazo ? Servicios de instalaci?n estandar incluidos ? Mantenimiento licencisas no incluido. ? ?Pack SaaS+Cloud - 6 usuarios El mejor ERP, sin inversi?n inicial y adem?s en la nube. ? Sin inversi?n inicial ? No necesita tener el servidor en su oficina ? Puede variar el n?mero de usuarios si necesita ampliar o reducir ? Servicios de instalaci?n inclu?dos ? Mantenimiento licnecias inclu?do Si necesita menos de < 6 usuarios, su paquete es Starter Package: Starter Package desde 499? al mes A partir de 1 usuario: ? Financiaci?n a 12 meses ? Servicios de instalaci?n inclu?dos? ? Mantenimiento licencias no incluido? ? Alquiler Starter Package + Cloud server desde 399? al mes A partir de 1 usuario: ? ERP que se adapta a sus necesidades. ? Servicios de instalaci?n inclu?dos ? Mantenimiento licencias inclu?do M?dulos avanzados para SAP Business One exclusivos de Axalpha Consulting? M?dulo Comercial Avanzado, hecho para vender iPad Comercial es un m?dulo para SAP Business One dise?ado para facilitar las ventas de sus comerciales fuera de la oficina. Permite realizar pedidos, organizar visitas, consultar datos de clientes, etc. ? Las operaciones se almacenan en la base de datos de su dispositivo m?vil y son enviadas al servidor central cuando hay conexi?n a internet. M?s informaci?n Otros m?dulos avanzados para optimizar su negocio: Gesti?n de almac?n Completa gesti?n de almac?n desde el muelle de entrada hasta el Picking. M?s informaci?n ? Gesti?n de proyectos Planificaci?n de proyectos que permite el control de horas, gastos y costes. M?s informaci?n ? Conector tienda online Conecta tiendas Prestashop con SAP Business One autom?ticamente. M?s informaci?n M?dulo EDI Intercambio de documentos entre diferentes plataformas inform?ticas. M?s informaci?n ? Comercial avanzado Facilita las ventas de los comerciales fuera de su empresa. M?s informaci?n ? Comercial b?sico Seguimiento comercial en movilidad. M?s informaci?n eFactura Env?a autom?ticamente sus facturas por correo electr?nico. M?s informaci?n ? M?dulo TPV Permite la venta en tienda sincronizada con SAP Business One. M?s informaci?n ? MRP Pron?sticos Ayuda a optimizar sus recursos y pedidos seg?n la demanda prevista. M?s informaci?n M?dulo SAT Asistencia t?cnica con todo el soporte en dispositivos m?viles. M?s informaci?n ? M?dulo observaciones Potente gesti?n de observaciones a nivel IC y documentos de marketing. M?s informaci?n ? M?dulo MasterData Validaci?n de cuentas bancarias, NIF y migraci?n para formato SEPA. M?s informaci?n M?dulos Modelo Hacienda Presentaci?n telem?tica de modelos 111, 115, 180, 190, 390 y 303 de Hacienda. M?s informaci?n ? M?dulo Confirming Gesti?n de pagos de proveedores y financiaci?n. M?s informaci?n ? Expediente de compras Agrupaci? de documentos de compra con documentaci?n de aduana. M?s informaci?n Plantillas Crystal Reports M?dulo con plantillas optimizadas para impresi?n de alto rendimiento. M?s informaci?n ? M?dulo A3n?mina Conexi?n con A3 n?mina para crear asiento de n?mina. M?s informaci?n ? M?dulo transportista Integraci?n de transportista UPS y SEUR. M?s informaci?n M?dulo tarjetas fichadoras Control de entradas y salidas con m?quinas fichadoras. M?s informaci?n ? Promociones y descuentos Gesti?n ?ptima de sus ofertas de venta. M?s informaci?n ? Introducci?n de gastos M?dulo para la gesti?n de notas de gastos. M?s informaci?n ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? En cumplimiento de la Ley 34/2002 del 11 de julio de Servicios de la Sociedad de la Informaci?n y de Comercio Electr?nico, le informamos que puede darse de baja de la recepci?n de nuestros boletines electr?nicos solicit?ndolo en el siguiente enlace: darse de baja -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Nov 19 21:15:34 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 19 Nov 2014 15:15:34 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <87egszkmwr.fsf@galex-713.eu> References: <20141117123333r0zhFV1NVJ@goodcrypto.com> <87d28mq6c9.fsf@vigenere.g10code.de> <20141117171016.Horde._lxZbB2lzBMx-0MWF4UQFg2@webmail.df.eu> <546A2A0F.3020704@sixdemonbag.org> <20141118151429.GA917@IUPUI.Edu> <546B6F21.2050705@sixdemonbag.org> <87y4r8kre4.fsf@galex-713.eu> <546BE4FB.9080903@sixdemonbag.org> <546C7C3F.4070903@digitalbrains.com> <546CD0A6.7060704@sixdemonbag.org> <87egszkmwr.fsf@galex-713.eu> Message-ID: <546CFA66.6000107@sixdemonbag.org> > He?s mainly explaining how do you fight spam in a centralized way, and > then explain how all the centralized techiques are unusable when using > crypto. That?s normal, crypto and decentralization comes together. You > need to think according other paradigms. And the point I'm making is this: this setup, which works, is what we will have to discard and replace if we move to E2E crypto. I'm not saying decentralized systems can't work. I'm saying that before we throw out our current system, we need to look long and hard at what it does, why it does it, and how effective it is -- because as soon as we adopt E2E crypto this thing goes completely away and we're going to need to rebuild it in a quite different way. > I don?t consider that an issue. Quite the opposite: the result ?and we > always end finding it? is *beautiful*. No, you don't always end up finding it (where 'it' is 'a decentralized algorithm that offers efficiency equivalent to a centralized algorithm'). There are many algorithms that have no known equivalently-performing decentralized alternative, algorithms where global knowledge is strictly necessary. Decentralized algorithms also have really interesting failure modes. Back in 2008, a one-bit error in Amazon's S3 cloud propagated from one node to the next and ultimately brought the entire thing down for several hours. It was a brilliant example of both error propagation and the limits of Byzantine fault tolerance.[1] I'm a firm believer that decentralized algorithms are a good thing, but let's keep our sense of perspective, all right? They're not magic and they don't always beat centralized algorithms. [1] http://status.aws.amazon.com/s3-20080720.html -- a really fascinating read if you love decentralized algorithms. From rex.k at me.com Thu Nov 20 09:40:41 2014 From: rex.k at me.com (Rex Kneisley) Date: Thu, 20 Nov 2014 00:40:41 -0800 Subject: problems with pinentry-0.9.0 Message-ID: <003801d0049d$ab28d1a0$017a74e0$@me.com> Hello group, I'm sorry to keep turning to this group for help with things that may seem painfully obvious to all of you. I am attempting to install GnuPG modern 2.1.0 on a clean install of Debian 7.7.0 amd64 I installed the development tools using the Debian "add/remove software" application. I have downloaded all of the packages. GnuPG modern 2.1.0 3039k download download Libgpg-error 1.17 654k download download Libgcrypt 1.6.2 2418k download download Libksba 1.3.1 584k download download Libassuan 2.1.3 504k download download Pinentry 0.9.0 453k download download GPGME 1.5.1 943k download download GPA 0.9.5 716k download download Dirmngr 1.1.0 543k download download I have verified each package signature with the GPG (1.4.12) that came with Debian using Werner's public key I have successfully "configured, made and installed" all of the required libraries in order. npth (ftp://ftp.gnupg.org/gcrypt/npth/) libgpg-error (ftp://ftp.gnupg.org/gcrypt/libgpg-error/) libgcrypt (ftp://ftp.gnupg.org/gcrypt/libgcrypt/) libksba (ftp://ftp.gnupg.org/gcrypt/libksba/) libassuan (ftp://ftp.gnupg.org/gcrypt/libassuan/) However, when I try to ./configure pinentry-0.9.0, It never completes successfully. I get quite a few no's and yes's I did install gawk and then tried again. But at the bottom I get: Checking pkg-config is at least version 0.9.0 . ./configure: line 8042: no: command not found No Checking for QT4_CORE. configure: error: No pinentry enabled Here is the full log: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... (cached) yes checking whether build environment is sane... yes checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking whether ln -s works... yes checking for windres... no checking for gitlog-to-changelog... no checking if gcc supports -Wno-pointer-sign... yes checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking termio.h usability... yes checking termio.h presence... yes checking for termio.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for seteuid... yes checking for stpcpy... yes checking for mmap... yes checking for mlock... yes checking whether mlock is broken... no checking for byte typedef... no checking for ulong typedef... yes checking for setcap... /sbin/setcap checking for cap_set_proc in -lcap... no checking for initscr in -lncursesw... no checking for initscr in -lncurses... no checking for tgetent in -lcurses... no checking for tgetent in -ltermcap... no checking for tgetent in -ltermlib... no checking for initscr in -lcurses... no checking for pkg-config... no checking pkg-config is at least version 0.9.0... ./configure: line 8042: no: command not found no checking for QT4_CORE... configure: error: No pinentry enabled. I suspect I am missing some dependencies. Is there a way to install this package that also grabs and installs dependencies similar to Homebrew on a Mac? Thanks for taking the time to help. Rex -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Nov 20 16:23:34 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 16:23:34 +0100 Subject: problems with pinentry-0.9.0 In-Reply-To: <003801d0049d$ab28d1a0$017a74e0$@me.com> (Rex Kneisley's message of "Thu, 20 Nov 2014 00:40:41 -0800") References: <003801d0049d$ab28d1a0$017a74e0$@me.com> Message-ID: <87lhn5lwuh.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 09:40, rex.k at me.com said: > checking for pkg-config... no Install the pkg-config package: apt-get install pkg-config Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shea at shealevy.com Thu Nov 20 15:07:42 2014 From: shea at shealevy.com (Shea Levy) Date: Thu, 20 Nov 2014 09:07:42 -0500 Subject: Backup of encrypted private key on uncontrolled disks Message-ID: Hi all, My private key is encrypted with a very strong passphrase (10 word diceware [1], not written down, 129 bits of entropy). Given that, is it safe to back it up on disks I don't control, such as a private S3 bucket or a VPS? My intuition says yes, but I've learned to never trust my intuition when it comes to security. Cheers,? Shea [1] http://www.diceware.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Nov 20 17:27:50 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 20 Nov 2014 11:27:50 -0500 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: References: Message-ID: <546E1686.7070204@sixdemonbag.org> > My private key is encrypted with a very strong passphrase (10 word > diceware [1], not written down, 129 bits of entropy). Given that, is it > safe to back it up on disks I don't control, such as a private S3 bucket > or a VPS? My intuition says yes, but I've learned to never trust my > intuition when it comes to security. If you are completely confident that no one will ever get your passphrase from you, this is safe. Otherwise, it's not. It may be appropriate to have a little caution with respect to whether you believe anyone will ever get your passphrase from you. From shea at shealevy.com Thu Nov 20 17:54:38 2014 From: shea at shealevy.com (Shea Levy) Date: Thu, 20 Nov 2014 11:54:38 -0500 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: <546E1686.7070204@sixdemonbag.org> References: <546E1686.7070204@sixdemonbag.org> Message-ID: <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> Hmm, I?m having a hard time imagining how someone could get me to divulge the passphrase if they couldn?t also get me to hand over the key backups I own. Of course, my imagination is not the limit here, so is there something I?m missing? Thanks, Shea > On Nov 20, 2014, at 11:27 AM, Robert J. Hansen wrote: > >> My private key is encrypted with a very strong passphrase (10 word >> diceware [1], not written down, 129 bits of entropy). Given that, is it >> safe to back it up on disks I don't control, such as a private S3 bucket >> or a VPS? My intuition says yes, but I've learned to never trust my >> intuition when it comes to security. > > If you are completely confident that no one will ever get your passphrase from you, this is safe. Otherwise, it's not. > > It may be appropriate to have a little caution with respect to whether you believe anyone will ever get your passphrase from you. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From brian at minton.name Thu Nov 20 17:12:08 2014 From: brian at minton.name (Brian Minton) Date: Thu, 20 Nov 2014 11:12:08 -0500 Subject: gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits Message-ID: I'm seeing an interesting message when encrypting and signing with my ECDSA/EDDSA subkeys. The encryption and signing seems to work, so it's mainly just an informational message: bminton at bminton:~$ echo hi|gpg2 -u 0424DC19B678A1A9 -r 0424DC19B678A1A9 -a -e -s gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits -----BEGIN PGP MESSAGE----- Version: GnuPG v2 [snip] -----END PGP MESSAGE----- bminton at bminton:~$ echo hi|gpg2 -u 0424DC19B678A1A9 -r 0424DC19B678A1A9 -a -e -s|gpg2 gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits gpg: encrypted with 384-bit ECDH key, ID EA49CFDB55D113E9, created 2014-10-12 "Brian Minton " hi gpg: Signature made Thu Nov 20 11:06:18 2014 EST gpg: using EDDSA key 37B9507ACFF2016E gpg: Good signature from "Brian Minton " [ultimate] gpg: aka "Brian Minton " [ultimate] From brian at minton.name Thu Nov 20 17:21:40 2014 From: brian at minton.name (Brian Minton) Date: Thu, 20 Nov 2014 11:21:40 -0500 Subject: gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits In-Reply-To: References: Message-ID: oops, I meant to say I have an ECDH and EDDSA subkey, but no ECDSA. On Thu, Nov 20, 2014 at 11:12 AM, Brian Minton wrote: > I'm seeing an interesting message when encrypting and signing with my > ECDSA/EDDSA subkeys. The encryption and signing seems to work, so > it's mainly just an informational message: > > bminton at bminton:~$ echo hi|gpg2 -u 0424DC19B678A1A9 -r 0424DC19B678A1A9 -a -e -s > gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits > -----BEGIN PGP MESSAGE----- > Version: GnuPG v2 > > [snip] > -----END PGP MESSAGE----- > bminton at bminton:~$ echo hi|gpg2 -u 0424DC19B678A1A9 -r > 0424DC19B678A1A9 -a -e -s|gpg2 > gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits > gpg: encrypted with 384-bit ECDH key, ID EA49CFDB55D113E9, created 2014-10-12 > "Brian Minton " > hi > gpg: Signature made Thu Nov 20 11:06:18 2014 EST > gpg: using EDDSA key 37B9507ACFF2016E > gpg: Good signature from "Brian Minton " [ultimate] > gpg: aka "Brian Minton " [ultimate] From dave at wiredthing.com Thu Nov 20 18:33:52 2014 From: dave at wiredthing.com (Dave English) Date: Thu, 20 Nov 2014 17:33:52 +0000 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> References: <546E1686.7070204@sixdemonbag.org> <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> Message-ID: Hint: do you always wear a hood over your head and the keyboard when entering your passphrase? ATB Dave English > On 20 Nov 2014, at 16:54, Shea Levy wrote: > > Hmm, I?m having a hard time imagining how someone could get me to divulge the passphrase if they couldn?t also get me to hand over the key backups I own. Of course, my imagination is not the limit here, so is there something I?m missing? > > Thanks, > Shea > >> On Nov 20, 2014, at 11:27 AM, Robert J. Hansen wrote: >> >>> My private key is encrypted with a very strong passphrase (10 word >>> diceware [1], not written down, 129 bits of entropy). Given that, is it >>> safe to back it up on disks I don't control, such as a private S3 bucket >>> or a VPS? My intuition says yes, but I've learned to never trust my >>> intuition when it comes to security. >> >> If you are completely confident that no one will ever get your passphrase from you, this is safe. Otherwise, it's not. >> >> It may be appropriate to have a little caution with respect to whether you believe anyone will ever get your passphrase from you. >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ndk.clanbo at gmail.com Thu Nov 20 19:43:28 2014 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 20 Nov 2014 19:43:28 +0100 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: References: <546E1686.7070204@sixdemonbag.org> <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> Message-ID: <546E3650.1090001@gmail.com> Il 20/11/2014 18:33, Dave English ha scritto: > Hint: do you always wear a hood over your head and the keyboard when entering your passphrase? Could simply use different passphrases for regular use and backups... BYtE, Diego. From rjh at sixdemonbag.org Thu Nov 20 19:53:18 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 20 Nov 2014 13:53:18 -0500 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> References: <546E1686.7070204@sixdemonbag.org> <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> Message-ID: <546E389E.1000205@sixdemonbag.org> > Hmm, I?m having a hard time imagining how someone could get me to > divulge the passphrase if they couldn?t also get me to hand over the > key backups I own. Of course, my imagination is not the limit here, > so is there something I?m missing? http://en.wikipedia.org/wiki/Robin_Sage The people fooled by Robin Sage were all intelligence professionals of one stripe or another. These are people who have been vetted for their reliability and discretion, and who regularly get briefed about efforts by foreign powers to get information out of them. They were all aware of the risks. Despite this, they were fooled. It's really easy to point fingers at them and say, "man, what chumps." But the reality is none of us on this list are different than they are. We're human, with the same foibles and weaknesses, and I'm pretty sure Robin Sage would rip through this mailing list like a chainsaw. (For that matter, I have no reason to think one isn't doing so right now. It's worth thinking about.) From jeremy.reeve81 at gmail.com Thu Nov 20 19:01:02 2014 From: jeremy.reeve81 at gmail.com (Jeremy Reeve) Date: Thu, 20 Nov 2014 18:01:02 +0000 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> References: <546E1686.7070204@sixdemonbag.org> <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> Message-ID: A keystroke logger? Jeremy On 20 November 2014 16:54, Shea Levy wrote: > Hmm, I?m having a hard time imagining how someone could get me to divulge > the passphrase if they couldn?t also get me to hand over the key backups I > own. Of course, my imagination is not the limit here, so is there something > I?m missing? > > Thanks, > Shea > > > On Nov 20, 2014, at 11:27 AM, Robert J. Hansen > wrote: > > > >> My private key is encrypted with a very strong passphrase (10 word > >> diceware [1], not written down, 129 bits of entropy). Given that, is it > >> safe to back it up on disks I don't control, such as a private S3 bucket > >> or a VPS? My intuition says yes, but I've learned to never trust my > >> intuition when it comes to security. > > > > If you are completely confident that no one will ever get your > passphrase from you, this is safe. Otherwise, it's not. > > > > It may be appropriate to have a little caution with respect to whether > you believe anyone will ever get your passphrase from you. > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Nov 20 20:11:13 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Nov 2014 20:11:13 +0100 Subject: gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits In-Reply-To: (Brian Minton's message of "Thu, 20 Nov 2014 11:12:08 -0500") References: Message-ID: <8761e9lmb2.fsf@vigenere.g10code.de> On Thu, 20 Nov 2014 17:12, brian at minton.name said: > ECDSA/EDDSA subkeys. The encryption and signing seems to work, so > it's mainly just an informational message: Actually this revealed a real bug: The code to figure out the best matching hash algorithm for ECDSA was not anymore working. Fixed with commit f80c2dd. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From brian at minton.name Thu Nov 20 20:24:39 2014 From: brian at minton.name (Brian Minton) Date: Thu, 20 Nov 2014 14:24:39 -0500 Subject: gpg: ECDSA public key is expected to be in SEC encoding multiple of 8 bits In-Reply-To: <8761e9lmb2.fsf@vigenere.g10code.de> References: <8761e9lmb2.fsf@vigenere.g10code.de> Message-ID: I put in a bug report: issue 1769 on http://bugs.g10code.com/gnupg On Thu, Nov 20, 2014 at 2:11 PM, Werner Koch wrote: > On Thu, 20 Nov 2014 17:12, brian at minton.name said: >> ECDSA/EDDSA subkeys. The encryption and signing seems to work, so >> it's mainly just an informational message: > > Actually this revealed a real bug: The code to figure out the best > matching hash algorithm for ECDSA was not anymore working. Fixed with > commit f80c2dd. > > Thanks, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From dave.pawson at gmail.com Thu Nov 20 19:40:05 2014 From: dave.pawson at gmail.com (Dave Pawson) Date: Thu, 20 Nov 2014 18:40:05 +0000 Subject: Symmetrical encryption or ... Message-ID: Requirement. Two machines (one Linux, one Windows). I want a secure file 'shared' between them, as a pwd-safe. Only I use the two machines, but need the file encrypted. Any alternatives to symmetrical encryption of a file? TiA, -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From rex.k at me.com Thu Nov 20 21:31:53 2014 From: rex.k at me.com (Rex Kneisley) Date: Thu, 20 Nov 2014 12:31:53 -0800 Subject: problems with pinentry-0.9.0 (Werner Koch) Message-ID: <004701d00501$05e95bb0$11bc1310$@me.com> Gracious reply: >Install the pkg-config package: >apt-get install pkg-config >Shalom-Salam, >Werner Thank you! After installing pkg-config as suggested, Looks like I'm down to the wire: checking whether mlock is broken... no checking for byte typedef... no checking for ulong typedef... yes checking for setcap... /sbin/setcap checking for cap_set_proc in -lcap... no checking for initscr in -lncursesw... no checking for initscr in -lncurses... no checking for tgetent in -lcurses... no checking for tgetent in -ltermcap... no checking for tgetent in -ltermlib... no checking for initscr in -lcurses... no checking for pkg-config... /usr/bin/pkg-config checking for gtk+-2... no configure: WARNING: pkg-config could not find the module gtk+-2.0 checking pkg-config is at least version 0.9.0... yes checking for QT4_CORE... no configure: error: No pinentry enabled. I have tried: sudo apt-get install gtk+-2 I get: Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'gir1.2-gtk-2.0' for regex 'gtk+-2' Note, selecting 'libspice-client-gtk-2.0-1' for regex 'gtk+-2' Note, selecting 'gir1.0-gtk-2.0' for regex 'gtk+-2' 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. With the same ./configure results Rex Kneisley 818-429-7472 rek.k at me.com Want to keep your emails private? Ask me how. Public OpenPGP key 0x393214E81D291F8C at hkp://pool.sks-keyservers.net Fingerprint=3D1A 46CB 14EF C5DF 68BA 3554 3932 14E8 1D29 1F8C Got bitcoins? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 owEBPAHD/pANAwACATkyFOgdKR+MAcsMYgBUXad4RGRkDQogiQEcBAABAgAGBQJU Xad4AAoJEDkyFOgdKR+MhvUH/jmzcbRrm+kDlBCcBCHNmGMZ2jWFZZm2HLprjaoj Qtybh0f/dRjpWoOr8l04IaxH1Wwiqt+DYXXy2ZBcXAwLmzMbucH6AAWu+meDl1zG qzw9FjLuEJ+W+vu5s7byVnlLbk3pynwrwtPwvsyv36POQTh/jjuh/MgEKNzZikKs c+gb87Dm9Qvv0NDSzAAwnXPnx6OmCNzTgwFAlcCwgKcCmg3WDZR4RAzY0JXRx/Ev fi2En8UYMBES5iVASh+Bw1185TCe9gt5kewAH/4Xt9teEkA+YOUsQBfY05rguo9O E05dv2CM1r2AvyzHf6yKtCVTHPTcKpFzCWxopUI2fbk34EI= =/h8w -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 2989 bytes Desc: not available URL: From kloecker at kde.org Thu Nov 20 22:54:50 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 20 Nov 2014 22:54:50 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: <448302142.20141118224318@my_localhost> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> <448302142.20141118224318@my_localhost> Message-ID: <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> On Tuesday 18 November 2014 22:43:18 MFPA wrote: > On Tuesday 18 November 2014 at 6:15:57 PM, in > , Mirimir wrote: > > As long as messages were separately encrypted to each > > recipient, no third parties would be involved. > > For an email message with multiple recipients, I think most mail > clients and OpenPGP encryption agents that I have looked at encrypt > the message to all addressees at once. I only recall one combination > that encrypted an individual copy for each addressee, and am not sure > I correctly remember which it was. KMail encrypts an individual copy for each BCC recipient. I thought Thunderbird+Enigmail would also do this. Any mail client not doing this completely subverts BCC (unless --throw-keyids or --hidden-recipient is used, but even throwing the key IDs still leaks the number of hidden recipients). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aarcane at aarcane.org Thu Nov 20 23:36:35 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Thu, 20 Nov 2014 14:36:35 -0800 Subject: Encryption on Mailing lists sensless? In-Reply-To: <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> <448302142.20141118224318@my_localhost> <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> Message-ID: On Nov 20, 2014 1:58 PM, "Ingo Kl?cker" wrote: > > On Tuesday 18 November 2014 22:43:18 MFPA wrote: > KMail encrypts an individual copy for each BCC recipient. I thought > Thunderbird+Enigmail would also do this. > > Any mail client not doing this completely subverts BCC (unless --throw-keyids > or --hidden-recipient is used, but even throwing the key IDs still leaks the > number of hidden recipients). There's nothing preventing a list server or mail client from intentionally adding a pseudo random quantity of invalid or junk keys to the recipient list, thus obfuscating the number of additional recipients, only providing an upper bound to the estimate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexanderino at gmail.com Fri Nov 21 07:25:41 2014 From: alexanderino at gmail.com (Jason Antony) Date: Fri, 21 Nov 2014 17:25:41 +1100 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> References: <546E1686.7070204@sixdemonbag.org> <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> Message-ID: <546EDAE5.2090409@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-21 03:54, Shea Levy wrote: > Hmm, I?m having a hard time imagining how someone could get me to > divulge the passphrase if they couldn?t also get me to hand over > the key backups I own. Of course, my imagination is not the limit > here, so is there something I?m missing? It's not easy to withstand rubber-hose cryptanalysis for long periods of time: http://xkcd.com/538/ Cheers, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUbtrjAAoJED1Q2DsLuMaGqLYP/jl8lN2/3kzPcyxZzp4AfMna 18uCQo+MQHNbEW4J2YxOtfjvWhXqvmwPX9eX+6zIoqzr9sEQLcCHQbjD6sCOfna+ BDXXA3JUQcCziFnkD71GqcHgx1OkgQE5OF7aJRObE6EFr0egNIXq5wL5bSlEcZnz NkumnqFCrMBKRP4AlZdnCtcAXCitTWEj/uuKG5zhNQlOzexi330Mn7INL98w3LZy swpkwTKQ8d7FRWvvNizw5vXmV44KstTSf1/5JTNNfXSNUEY1tJhDFwGimEfUi5N9 R+DuDT5gb5Z/JApPhxAHdIii8rdGETcAw5JM7w9xkNgTmrn9jbKokpaaQgp1pEKm 2RA8kUiKRXnW2mQFpQe8Iwv2AuGCPPYwFNgbM0GiX0Z7LWJ/U4jXyLoijrCeozCJ gQcMTzxoRm1GvVDWorq0YkLYOraAaPCbDvi+xW5JN/XX8zuqPfOouHCsrNnjvqOu UkT607podLWwJ0CTR6yUcCPNCJ4DdGRpq7AofF96QqtvwiXA2BVRAUm7jb566Tdz GXmLRvK76Bub9ZqoC7TgK2aSuNLtab+8NsiZCugj2jMiDvzLhvY1y6m+jbVyvlCp lD9ZBeDvZDsTgwt0So8ce6zafF2p/aVNkiBevcF5EnO1OV2Wu/iop20nf93smD9O DDLY8XGTMb8AgMB4Zg2W =NeYL -----END PGP SIGNATURE----- From roam at ringlet.net Fri Nov 21 08:56:02 2014 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 21 Nov 2014 09:56:02 +0200 Subject: problems with pinentry-0.9.0 (Werner Koch) In-Reply-To: <004701d00501$05e95bb0$11bc1310$@me.com> References: <004701d00501$05e95bb0$11bc1310$@me.com> Message-ID: <20141121075602.GB3835@straylight.m.ringlet.net> On Thu, Nov 20, 2014 at 12:31:53PM -0800, Rex Kneisley wrote: > Gracious reply: > >Install the pkg-config package: > >apt-get install pkg-config > >Shalom-Salam, > >Werner > > Thank you! > After installing pkg-config as suggested, > Looks like I'm down to the wire: > > checking whether mlock is broken... no > checking for byte typedef... no > checking for ulong typedef... yes > checking for setcap... /sbin/setcap > checking for cap_set_proc in -lcap... no > checking for initscr in -lncursesw... no > checking for initscr in -lncurses... no > checking for tgetent in -lcurses... no > checking for tgetent in -ltermcap... no > checking for tgetent in -ltermlib... no > checking for initscr in -lcurses... no > checking for pkg-config... /usr/bin/pkg-config > checking for gtk+-2... no > configure: WARNING: pkg-config could not find the module gtk+-2.0 > checking pkg-config is at least version 0.9.0... yes > checking for QT4_CORE... no > configure: error: No pinentry enabled. > > I have tried: > > sudo apt-get install gtk+-2 If you need to build programs with GTK+ 2.0 support, the package that you need to install is usually named something like libgtk2.0-dev on Debian-like systems. This information is actually available if you have "deb-src" lines in your /etc/apt/sources.list, so that Apt can download information about source packages; then you can try the following: apt-cache search -n pinentry (see that it shows a pinentry-gtk2 binary package) apt-cache show pinentry-gtk2 | less (it will tell you "Source: pinentry") apt-cache showsrc pinentry It will give you a list of packages in the Build-Depends field; those are packages that the Debian package of pinentry needs so that it can build properly with full support for all the backends. You might consider installing at least some of them. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at FreeBSD.org p.penchev at storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From aarcane at aarcane.org Fri Nov 21 10:57:06 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Fri, 21 Nov 2014 01:57:06 -0800 Subject: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext? Message-ID: I know some encryption schemes reveal more information about the keys used when an attacker has both the plaintext and the ciphertext. In general, how much information does GPG reveal in such situations? How much plaintext/ciphertext matched data would an attacker need (An order of magnitude is fine) before being able to reverse enough of the key to be meaningful on fairly modern computers? -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin-gnupg-users at dkyb.de Fri Nov 21 11:35:55 2014 From: martin-gnupg-users at dkyb.de (Martin Behrendt) Date: Fri, 21 Nov 2014 11:35:55 +0100 Subject: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext? In-Reply-To: References: Message-ID: <546F158B.8000100@dkyb.de> Am 21.11.2014 um 10:57 schrieb Schlacta, Christ: > I know some encryption schemes reveal more information about the keys used > when an attacker has both the plaintext and the ciphertext. In general, > how much information does GPG reveal in such situations? Short answer: Thats no problem. google e.g.: "plain text attacks on gnupg site:gnupg.org" Greetings Martin From rjh at sixdemonbag.org Fri Nov 21 15:47:35 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 21 Nov 2014 09:47:35 -0500 Subject: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext? In-Reply-To: References: Message-ID: <546F5087.5000504@sixdemonbag.org> > I know some encryption schemes reveal more information about the keys > used when an attacker has both the plaintext and the ciphertext. In > general, how much information does GPG reveal in such situations? Virtually none. > How much plaintext/ciphertext matched data would an attacker need (An > order of magnitude is fine) before being able to reverse enough of > the key to be meaningful on fairly modern computers? Enough to make it far, *far* more cost-effective to resort to other methods to recover your key. Just buying the hard drives alone would exhaust the budgets of large corporations. From fulanoperez at cryptolab.net Fri Nov 21 15:09:32 2014 From: fulanoperez at cryptolab.net (Fulano Diego Perez) Date: Sat, 22 Nov 2014 01:09:32 +1100 Subject: 2 pka dns RRs - same email address Message-ID: <546F479C.7000704@cryptolab.net> i know its not strictly for this list but does anybody have a suggestion for the zone file ? i have 2 TLSA RRs in my zone file, 2 certs, and postfix automatically selects the correct cert based on the RR what would gnupg do if it encountered 2 pka RRs ? would it select the correct finger print automatically ? From vedaal at nym.hush.com Fri Nov 21 16:56:51 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 21 Nov 2014 10:56:51 -0500 Subject: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext? In-Reply-To: Message-ID: <20141121155652.13A14A00FC@smtp.hushmail.com> On 11/21/2014 at 4:57 AM, "Christ Schlacta" wrote: >how much information does GPG reveal in such situations? ===== GnuPG works by using hybrid encryption: [1] The plaintext is converted to ciphertext using a block cipher, with GnuPG generating a random session key for the encryption [2] The random session key is then encrypted to the recipient's public key. [3] The recipient uses the private key to recover the session key in [2], which is then used to decrypt the plaintext in [1]. No amount of plaintext and ciphertext reveal anything about the recipient's *Private* key. (The recipient's public key is usually *public* and known already). That said, Any attacker can simultaneously encrypt to a 'Target' public key, and to the Attacker's own public key. The Attacker can then recover the session key by decrypting with the Attacker's private key. This 'session key' is the only thing that can be used as the "plaintext" that is encrypted to the Target's public key. An attacker now knows: (a) The *ciphertext*, which is the session key encrypted to the Target's public key. (b) *PART* of the *plaintext*, which is the session key, since it was encrypted to the attacker's public key. (It is only *part* because the session key is padded with a *different* padding for each key to which it is encrypted, even when the same session key is simultaneous encrypted to different public keys.) (c) The Target's Public key. The Attacker can generate an unlimited amount of messages in this way. Using this information the attacker now wants to find/reconstruct the Target's Private key. I don't know that much about attacking RSA Key Pairs in trying to find the Private Key, (other than factoring the modulus), but suffice it to say, that in the over 20 years that RSA has been around and many different attacks have been tried, *this* type of attack has not seemed feasible enough for anyone to try. So, Short summary, No useful information can be gleaned. vedaal From rjh at sixdemonbag.org Fri Nov 21 17:31:46 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 21 Nov 2014 11:31:46 -0500 Subject: Backup of encrypted private key on uncontrolled disks In-Reply-To: <546E389E.1000205@sixdemonbag.org> References: <546E1686.7070204@sixdemonbag.org> <312055A3-221C-427C-9017-A11D8519A692@shealevy.com> <546E389E.1000205@sixdemonbag.org> Message-ID: <546F68F2.3060309@sixdemonbag.org> > It's really easy to point fingers at them and say, "man, what > chumps." But the reality is none of us on this list are different > than they are. We're human, with the same foibles and weaknesses, and > I'm pretty sure Robin Sage would rip through this mailing list like a > chainsaw. For that matter, Eliezer Yudkowski's "AI in a Box" experiment shows just how prone people are to being gamed. (And yes, I was reminded of Yudkowski's work by seeing today's XKCD.) http://yudkowsky.net/singularity/aibox From aarcane at aarcane.org Fri Nov 21 19:00:19 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Fri, 21 Nov 2014 10:00:19 -0800 Subject: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext? In-Reply-To: <20141121155652.13A14A00FC@smtp.hushmail.com> References: <20141121155652.13A14A00FC@smtp.hushmail.com> Message-ID: So to summarize, the best way to try this attack would be to encrypt lots of small messages to a dummy key and a target key because the only knowable plaintext is the session key. However, there's no known or reasonably suspected method of plaintext attack anyway, so all this data is believed to be a waste. Correct me if I'm wrong, and thank you all for the prompt and consistent replies On Nov 21, 2014 7:59 AM, wrote: > On 11/21/2014 at 4:57 AM, "Christ Schlacta" wrote: > > >how much information does GPG reveal in such situations? > > ===== > > GnuPG works by using hybrid encryption: > > [1] The plaintext is converted to ciphertext using a block cipher, with > GnuPG generating a random session key for the encryption > > [2] The random session key is then encrypted to the recipient's public key. > > [3] The recipient uses the private key to recover the session key in [2], > which is then used to decrypt the plaintext in [1]. > > > No amount of plaintext and ciphertext reveal anything about the > recipient's *Private* key. > (The recipient's public key is usually *public* and known already). > > That said, > Any attacker can simultaneously encrypt to a 'Target' public key, and to > the Attacker's own public key. > > The Attacker can then recover the session key by decrypting with the > Attacker's private key. > This 'session key' is the only thing that can be used as the "plaintext" > that is encrypted to the Target's public key. > > > An attacker now knows: > > (a) The *ciphertext*, which is the session key encrypted to the Target's > public key. > > (b) *PART* of the *plaintext*, which is the session key, since it was > encrypted to the attacker's public key. > (It is only *part* because the session key is padded with a *different* > padding for each key to which it is encrypted, > even when the same session key is simultaneous encrypted to different > public keys.) > > (c) The Target's Public key. > > The Attacker can generate an unlimited amount of messages in this way. > > Using this information the attacker now wants to find/reconstruct the > Target's Private key. > > > I don't know that much about attacking RSA Key Pairs in trying to find > the Private Key, (other than factoring the modulus), > but suffice it to say, that in the over 20 years that RSA has been around > and many different attacks have been tried, > *this* type of attack has not seemed feasible enough for anyone to try. > > So, > Short summary, > > No useful information can be gleaned. > > > vedaal > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Fri Nov 21 19:20:04 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 21 Nov 2014 13:20:04 -0500 Subject: How much information can be gleaned about a gpg key by possessing both plaintext and ciphertext? In-Reply-To: References: <20141121155652.13A14A00FC@smtp.hushmail.com> Message-ID: <20141121182004.84255A0138@smtp.hushmail.com> On 11/21/2014 at 1:01 PM, "Christ Schlacta" wrote: > >So to summarize, the best way to try this attack would be to >encrypt lots >of small messages to a dummy key and a target key because the only >knowable >plaintext is the session key. However, there's no known or >reasonably >suspected method of plaintext attack anyway, so all this data is >believed >to be a waste. ===== Correct. You could (more efficiently) isolate the Public GnuPG key as an RSA Public key, and use an implementation of RSA that does not use padding, and try all the plaintexts and known resulting ciphertexts, and still not construct the RSA Private key. vedaal From rjh at sixdemonbag.org Fri Nov 21 19:24:02 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 21 Nov 2014 13:24:02 -0500 Subject: Symmetrical encryption or ... In-Reply-To: References: Message-ID: <546F8342.2090502@sixdemonbag.org> > Only I use the two machines, but need the file encrypted. > > Any alternatives to symmetrical encryption of a file? Not really. Sym would appear to be ideal for your use case. From dave.pawson at gmail.com Fri Nov 21 19:27:38 2014 From: dave.pawson at gmail.com (Dave Pawson) Date: Fri, 21 Nov 2014 18:27:38 +0000 Subject: Symmetrical encryption or ... In-Reply-To: <546F8342.2090502@sixdemonbag.org> References: <546F8342.2090502@sixdemonbag.org> Message-ID: Thanks Robert. I'll give it a try. regards Dave P On 21 November 2014 18:24, Robert J. Hansen wrote: >> Only I use the two machines, but need the file encrypted. >> >> Any alternatives to symmetrical encryption of a file? > > > Not really. Sym would appear to be ideal for your use case. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From aarcane at aarcane.org Fri Nov 21 19:36:21 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Fri, 21 Nov 2014 10:36:21 -0800 Subject: Symmetrical encryption or ... In-Reply-To: References: <546F8342.2090502@sixdemonbag.org> Message-ID: For a password safe you might look into existing solutions, such as keepass(x) or other similar password storage solutions On Nov 21, 2014 10:29 AM, "Dave Pawson" wrote: > Thanks Robert. I'll give it a try. > > regards Dave P > > On 21 November 2014 18:24, Robert J. Hansen wrote: > >> Only I use the two machines, but need the file encrypted. > >> > >> Any alternatives to symmetrical encryption of a file? > > > > > > Not really. Sym would appear to be ideal for your use case. > > > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > -- > Dave Pawson > XSLT XSL-FO FAQ. > Docbook FAQ. > http://www.dpawson.co.uk > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.pawson at gmail.com Fri Nov 21 20:58:41 2014 From: dave.pawson at gmail.com (Dave Pawson) Date: Fri, 21 Nov 2014 19:58:41 +0000 Subject: Symmetrical encryption or ... In-Reply-To: References: <546F8342.2090502@sixdemonbag.org> Message-ID: 1. A matter of trust (low) 2. One mc is Linux, the other windows - they tend not to mix? Tks, Dave On 21 November 2014 18:36, Schlacta, Christ wrote: > For a password safe you might look into existing solutions, such as > keepass(x) or other similar password storage solutions > > On Nov 21, 2014 10:29 AM, "Dave Pawson" wrote: >> >> Thanks Robert. I'll give it a try. >> >> regards Dave P >> >> On 21 November 2014 18:24, Robert J. Hansen wrote: >> >> Only I use the two machines, but need the file encrypted. >> >> >> >> Any alternatives to symmetrical encryption of a file? >> > >> > >> > Not really. Sym would appear to be ideal for your use case. >> > >> > >> > _______________________________________________ >> > Gnupg-users mailing list >> > Gnupg-users at gnupg.org >> > http://lists.gnupg.org/mailman/listinfo/gnupg-users >> >> >> >> -- >> Dave Pawson >> XSLT XSL-FO FAQ. >> Docbook FAQ. >> http://www.dpawson.co.uk >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From grantksupport at operamail.com Fri Nov 21 21:16:39 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 21 Nov 2014 12:16:39 -0800 Subject: correct usage of gpg param 'throw-keyid(s)' ? Message-ID: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> What is this param's correct usage: "throw-keyids" or "throw-keyid" ? I see conflicting docs online: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html & --throw-keyids --no-throw-keyids Do not put the recipient key IDs into encrypted messages. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis.1 On the receiving side, it may slow down the decryption process because all available secret keys must be tried. --no-throw-keyids disables this option. This option is essentially the same as using --hidden-recipient for all recipients. & https://www.gnupg.org/gph/en/manual/r2110.html Name throw-keyid ? do not put key IDs into encrypted packets Generally, which gpg docs are authoritative? https://www.gnupg.org/documentation/manuals, OR, https://www.gnupg.org/gph/en/manual ? I.e., if/when they conflict, which is considered correct? From mailinglisten at hauke-laging.de Fri Nov 21 22:52:46 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 21 Nov 2014 22:52:46 +0100 Subject: correct usage of gpg param 'throw-keyid(s)' ? In-Reply-To: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> References: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> Message-ID: <2036919.tJlkqnQcPs@inno> Am Fr 21.11.2014, 12:16:39 schrieb grantksupport at operamail.com: > I see conflicting docs online: > Do not put the recipient key IDs into encrypted messages. This > helps to hide the receivers of the message and is a limited > countermeasure against traffic analysis.1 On the receiving side, it > may slow down the decryption process because all available secret > keys must be tried. --no-throw-keyids disables this option. This > option is essentially the same as using --hidden-recipient for all > recipients. > throw-keyid ? do not put key IDs into encrypted packets And what do you consider the conflict? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From grantksupport at operamail.com Fri Nov 21 22:58:19 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 21 Nov 2014 13:58:19 -0800 Subject: correct usage of gpg param 'throw-keyid(s)' ? In-Reply-To: <2036919.tJlkqnQcPs@inno> References: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> <2036919.tJlkqnQcPs@inno> Message-ID: <1416607099.1765174.193965605.38569064@webmail.messagingengine.com> > And what do you consider the conflict? >> What is this param's correct usage: >> >> "throw-keyids" or "throw-keyid" >> >> ? The obvious difference in usage ... One says the usage is throw-keyids the other says usage is throw-keyid neither one mentions the others' usage From mailinglisten at hauke-laging.de Fri Nov 21 23:19:14 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 21 Nov 2014 23:19:14 +0100 Subject: correct usage of gpg param 'throw-keyid(s)' ? In-Reply-To: <1416607099.1765174.193965605.38569064@webmail.messagingengine.com> References: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> <2036919.tJlkqnQcPs@inno> <1416607099.1765174.193965605.38569064@webmail.messagingengine.com> Message-ID: <3337681.XhNSWIut9l@inno> Am Fr 21.11.2014, 13:58:19 schrieb grantksupport at operamail.com: > The obvious difference in usage ... > > One says the usage is > > throw-keyids > > the other says usage is > > throw-keyid That's just a typo. The correct name for the option is "throw-keyids". You do not have to write the complete name. It is enough to have so many chars that the option or command is unambiguous. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From dkg at fifthhorseman.net Fri Nov 21 23:33:34 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Nov 2014 17:33:34 -0500 Subject: correct usage of gpg param 'throw-keyid(s)' ? In-Reply-To: <1416607099.1765174.193965605.38569064@webmail.messagingengine.com> References: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> <2036919.tJlkqnQcPs@inno> <1416607099.1765174.193965605.38569064@webmail.messagingengine.com> Message-ID: <546FBDBE.6030900@fifthhorseman.net> On 11/21/2014 04:58 PM, grantksupport at operamail.com wrote: > The obvious difference in usage ... > > One says the usage is > > throw-keyids > > the other says usage is > > throw-keyid > > neither one mentions the others' usage As long as the prefix substring is unique, gpg will accept a truncated long-option. That is, the full option is --throw-keyids, but gpg will accept --throw-keyid as an alias for it. It should also accept --throw-keyi and --throw-key and --throw-ke to mean the same thing, but it doesn't due to a quirk of the source code (i've just mailed a patch to gnupg-devel to fix that). Good documentation should always use the full option, to avoid ambiguity with any potential future updates. I'd say the GNU privacy handbook should be updated to use --throw-keyids instead of --throw-keyid. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From grantksupport at operamail.com Fri Nov 21 23:38:27 2014 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 21 Nov 2014 14:38:27 -0800 Subject: correct usage of gpg param 'throw-keyid(s)' ? In-Reply-To: <546FBDBE.6030900@fifthhorseman.net> References: <1416600999.1745114.193933509.38871A83@webmail.messagingengine.com> <2036919.tJlkqnQcPs@inno> <1416607099.1765174.193965605.38569064@webmail.messagingengine.com> <546FBDBE.6030900@fifthhorseman.net> Message-ID: <1416609507.1772245.193976933.4116143C@webmail.messagingengine.com> On Fri, Nov 21, 2014, at 02:33 PM, Daniel Kahn Gillmor wrote: > As long as the prefix substring is unique, gpg will accept a truncated > long-option. > > That is, the full option is --throw-keyids, but gpg will accept > --throw-keyid as an alias for it. > > It should also accept --throw-keyi and --throw-key and --throw-ke to > mean the same thing, but it doesn't due to a quirk of the source code > (i've just mailed a patch to gnupg-devel to fix that). > > Good documentation should always use the full option, to avoid ambiguity > with any potential future updates. I'd say the GNU privacy handbook > should be updated to use --throw-keyids instead of --throw-keyid. Thanks for the clarification, and the prompt fixes. Appreciated! From dougb at dougbarton.email Sat Nov 22 03:37:03 2014 From: dougb at dougbarton.email (Doug Barton) Date: Fri, 21 Nov 2014 18:37:03 -0800 Subject: Symmetrical encryption or ... In-Reply-To: References: Message-ID: <546FF6CF.3080400@dougbarton.email> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/20/14 10:40 AM, Dave Pawson wrote: | Requirement. Two machines (one Linux, one Windows). | | I want a secure file 'shared' between them, as a pwd-safe. | | Only I use the two machines, but need the file encrypted. | | Any alternatives to symmetrical encryption of a file? Either symmetric or PK encryption would suit your needs, but as someone pointed out already, a better solution is to use a password safe. KeePass is an excellent solution, and I use the same password db between Windows, Linux, and OS X (not in that order). :) You want to use the lowest common denominator format between those systems, which at this point is the 1.28 version for Windows, and the keepassx version that comes with most Linux distributions (I use Ubuntu primarily). For OS X it gets a little trickier, since the version that includes auto-type is community sourced, but the person who produces it is well trusted, and a lot of people use it. Schneier had an interesting blog post recently about password safes, with a link to papers that did extensive research on them. KeePass came out looking pretty good, as one of the key problems with most password safes is that if the auto-type is truly automatic, it can be triggered by malicious software and grab your passwords off the clipboard in windows. While KeePass does have an auto-type feature, you have to trigger the key sequence to use it, and that sequence is user-configurable. And obviously you don't want to use solutions like LastPass, where your stuff is stored in their cloud. The question of "What if they get hacked?" is no longer academic, since it happened recently. For synchronization between systems I use SpiderOak, which also has clients for all 3 platforms. KeePass already encrypts the db file, and SpiderOak, unlike most "cloud storage" platforms, encrypts the files it backs up locally (on your system) with a special key that the company does not know. The upload channel is encrypted to their servers as well, so your data is never available in the clear. Because they don't know the encryption key your data is never de-duplicated with other people's stuff, although if you set up folder synchronization between systems the same files will be de-duplicated within your own account. ... and speaking of folder synchronization, one of the things I like about SpiderOak is that you can set up arbitrary folders to synchronize between systems, you don't have to put all of your stuff in one folder. You can also configure it to exclude certain files from syncing, which is handy to avoid synching the .lock file for KeePass. :) http://keepass.info/index.html https://www.schneier.com/blog/archives/2014/09/security_of_pas.html If you use this link to sign up for SpiderOak, I get free space. :) https://spideroak.com/signup/referral/25c4971714a13f13c24fa98a43317dc2/ Or, here is the regular link, if you prefer: https://spideroak.com/ hope this helps, Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUb/bPAAoJEFzGhvEaGryEq9EH/0pwRxi7PpJMlJs9yGOvdcBO +oqL6uJ99U72kdmUeznLzSewN5pHJoKB26gHAqs2WvNnoNGDOfRKz89ijKxCOWbE 8uJfz+AEqDJLe6CdLXSVTTa8SdLDydYUqrQZuV3aPxVPCCA91I4vi0HVB3MAlqLV ndOEaX6wP6/GCqVDkHUDQ9V37jmFHa7jl2RKFXj5BRL31ztQuqVQ4VlCiVbZFvje aipBL8p1l9EBdEUdQIM7tnykeP9EY+0F5zQmSqAuxxk+CFKQZBJ2FqZN1bnvi5OC QQFaUy4sGQKdI/uoOQOVM5YHXzQxJ6tZY1zFUudQwcs/Sdi2EQkRZQVOpMHeeqQ= =dI3t -----END PGP SIGNATURE----- From kloecker at kde.org Sat Nov 22 00:49:00 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 22 Nov 2014 00:49:00 +0100 Subject: Encryption on Mailing lists sensless? In-Reply-To: References: <20141118173033xCi55Ehu8G@goodcrypto.com> <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> Message-ID: <4390134.Ez0F65sz4s@collossus.ingo-kloecker.de> On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote: > On Nov 20, 2014 1:58 PM, "Ingo Kl?cker" wrote: > > On Tuesday 18 November 2014 22:43:18 MFPA wrote: > > KMail encrypts an individual copy for each BCC recipient. I thought > > Thunderbird+Enigmail would also do this. > > > > Any mail client not doing this completely subverts BCC (unless > > --throw-keyids > > > or --hidden-recipient is used, but even throwing the key IDs still leaks > > the > > > number of hidden recipients). > > There's nothing preventing a list server or mail client from intentionally > adding a pseudo random quantity of invalid or junk keys to the recipient > list, thus obfuscating the number of additional recipients, only providing > an upper bound to the estimate. Adding additional junk keys doesn't help if the recipient (or the recipients) expect a certain number of recipients. If the message is encrypted to more than (expected number of recipients)+1 (for encrypt to sender) then the recipients most likely will wonder who the other recipients are. You'll have a hard time convincing them that the "other recipients" are just fakes to confuse a third party intercepting the messages. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From aarcane at aarcane.org Sat Nov 22 06:04:34 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Fri, 21 Nov 2014 21:04:34 -0800 Subject: Encryption on Mailing lists sensless? In-Reply-To: <4390134.Ez0F65sz4s@collossus.ingo-kloecker.de> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> <4390134.Ez0F65sz4s@collossus.ingo-kloecker.de> Message-ID: On Nov 21, 2014 8:55 PM, "Ingo Kl?cker" wrote: > > On Thursday 20 November 2014 14:36:35 Schlacta, Christ wrote: > > On Nov 20, 2014 1:58 PM, "Ingo Kl?cker" wrote: > > > On Tuesday 18 November 2014 22:43:18 MFPA wrote: > > > KMail encrypts an individual copy for each BCC recipient. I thought > > > Thunderbird+Enigmail would also do this. > > > > > > Any mail client not doing this completely subverts BCC (unless > > > > --throw-keyids > > > > > or --hidden-recipient is used, but even throwing the key IDs still leaks > > > > the > > > > > number of hidden recipients). > > > > There's nothing preventing a list server or mail client from intentionally > > adding a pseudo random quantity of invalid or junk keys to the recipient > > list, thus obfuscating the number of additional recipients, only providing > > an upper bound to the estimate. > > Adding additional junk keys doesn't help if the recipient (or the recipients) > expect a certain number of recipients. If the message is encrypted to more > than (expected number of recipients)+1 (for encrypt to sender) then the > recipients most likely will wonder who the other recipients are. You'll have a > hard time convincing them that the "other recipients" are just fakes to > confuse a third party intercepting the messages. Perhaps a future version of the pgp specification should say something akin to gpg should always add a number of junk keys, perhaps to pad the key list out to one from a list of constant sizes, just to ensure that nobody can know for sure how many recipients there are (except the sender), and can at best place an upper bound. Perhaps the valid keys should be placed pseudorandomly throughout the constant sized key table -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.pawson at gmail.com Sat Nov 22 07:28:20 2014 From: dave.pawson at gmail.com (Dave Pawson) Date: Sat, 22 Nov 2014 06:28:20 +0000 Subject: Symmetrical encryption or ... In-Reply-To: <546FF6CF.3080400@dougbarton.email> References: <546FF6CF.3080400@dougbarton.email> Message-ID: Thanks Doug On 22 November 2014 02:37, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Either symmetric or PK encryption would suit your needs, but as > someone pointed out already, a better solution is to use a password safe. > > KeePass is an excellent solution, and I use the same password db > between Windows, Linux, and OS X (not in that order). :) You want to > use the lowest common denominator format between those systems, which > at this point is the 1.28 version for Windows, and the keepassx > version that comes with most Linux distributions (I use Ubuntu > primarily). Noted. typically Secure access requires n items, login/pwd/mothers maiden name/ inside leg measurement etc... Can keepassx store a list of key:value pairs? I know some systems are restrictive in this area. I'm currently running Python code which dumps the dictionary content for use, direct from the decryption. So where do you store the data? Online for access from 3 machines? Dropbox? Seems an unnecessary exposure. I'll have a look. > > And obviously you don't want to use solutions like > LastPass, where your stuff is stored in their cloud. The question of > "What if they get hacked?" is no longer academic, since it happened > recently. Yes... > > For synchronization between systems I use SpiderOak, which also has > clients for all 3 platforms. KeePass already encrypts the db file, and > SpiderOak, unlike most "cloud storage" platforms, encrypts the files > it backs up locally (on your system) with a special key that the > company does not know. Another exposure? At least with a symmetrical encryption the files are only local... (Am I being too cautious?) > http://keepass.info/index.html > > https://www.schneier.com/blog/archives/2014/09/security_of_pas.html > > If you use this link to sign up for SpiderOak, I get free space. :) > https://spideroak.com/signup/referral/25c4971714a13f13c24fa98a43317dc2/ Thanks Doug. More options. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUb/bPAAoJEFzGhvEaGryEq9EH/0pwRxi7PpJMlJs9yGOvdcBO > +oqL6uJ99U72kdmUeznLzSewN5pHJoKB26gHAqs2WvNnoNGDOfRKz89ijKxCOWbE > 8uJfz+AEqDJLe6CdLXSVTTa8SdLDydYUqrQZuV3aPxVPCCA91I4vi0HVB3MAlqLV > ndOEaX6wP6/GCqVDkHUDQ9V37jmFHa7jl2RKFXj5BRL31ztQuqVQ4VlCiVbZFvje > aipBL8p1l9EBdEUdQIM7tnykeP9EY+0F5zQmSqAuxxk+CFKQZBJ2FqZN1bnvi5OC > QQFaUy4sGQKdI/uoOQOVM5YHXzQxJ6tZY1zFUudQwcs/Sdi2EQkRZQVOpMHeeqQ= > =dI3t > -----END PGP SIGNATURE----- > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From dave.pawson at gmail.com Sat Nov 22 08:54:18 2014 From: dave.pawson at gmail.com (Dave Pawson) Date: Sat, 22 Nov 2014 07:54:18 +0000 Subject: Symmetrical encryption or ... In-Reply-To: <546FF6CF.3080400@dougbarton.email> References: <546FF6CF.3080400@dougbarton.email> Message-ID: I installed keepassx. Not much use to me. 1. Illegible with my eyesight (reported to them) 2. Insufficient fields (seems to be non expandable). regards On 22 November 2014 02:37, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 11/20/14 10:40 AM, Dave Pawson wrote: > | Requirement. Two machines (one Linux, one Windows). > | > | I want a secure file 'shared' between them, as a pwd-safe. > | > | Only I use the two machines, but need the file encrypted. > | > | Any alternatives to symmetrical encryption of a file? > > Either symmetric or PK encryption would suit your needs, but as > someone pointed out already, a better solution is to use a password safe. > > KeePass is an excellent solution, and I use the same password db > between Windows, Linux, and OS X (not in that order). :) You want to > use the lowest common denominator format between those systems, which > at this point is the 1.28 version for Windows, and the keepassx > version that comes with most Linux distributions (I use Ubuntu > primarily). For OS X it gets a little trickier, since the version that > includes auto-type is community sourced, but the person who produces > it is well trusted, and a lot of people use it. > > Schneier had an interesting blog post recently about password safes, > with a link to papers that did extensive research on them. KeePass > came out looking pretty good, as one of the key problems with most > password safes is that if the auto-type is truly automatic, it can be > triggered by malicious software and grab your passwords off the > clipboard in windows. While KeePass does have an auto-type feature, > you have to trigger the key sequence to use it, and that sequence is > user-configurable. And obviously you don't want to use solutions like > LastPass, where your stuff is stored in their cloud. The question of > "What if they get hacked?" is no longer academic, since it happened > recently. > > For synchronization between systems I use SpiderOak, which also has > clients for all 3 platforms. KeePass already encrypts the db file, and > SpiderOak, unlike most "cloud storage" platforms, encrypts the files > it backs up locally (on your system) with a special key that the > company does not know. The upload channel is encrypted to their > servers as well, so your data is never available in the clear. Because > they don't know the encryption key your data is never de-duplicated > with other people's stuff, although if you set up folder > synchronization between systems the same files will be de-duplicated > within your own account. > > ... and speaking of folder synchronization, one of the things I like > about SpiderOak is that you can set up arbitrary folders to > synchronize between systems, you don't have to put all of your stuff > in one folder. You can also configure it to exclude certain files from > syncing, which is handy to avoid synching the .lock file for KeePass. :) > > http://keepass.info/index.html > > https://www.schneier.com/blog/archives/2014/09/security_of_pas.html > > If you use this link to sign up for SpiderOak, I get free space. :) > https://spideroak.com/signup/referral/25c4971714a13f13c24fa98a43317dc2/ > > Or, here is the regular link, if you prefer: > https://spideroak.com/ > > hope this helps, > > Doug > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJUb/bPAAoJEFzGhvEaGryEq9EH/0pwRxi7PpJMlJs9yGOvdcBO > +oqL6uJ99U72kdmUeznLzSewN5pHJoKB26gHAqs2WvNnoNGDOfRKz89ijKxCOWbE > 8uJfz+AEqDJLe6CdLXSVTTa8SdLDydYUqrQZuV3aPxVPCCA91I4vi0HVB3MAlqLV > ndOEaX6wP6/GCqVDkHUDQ9V37jmFHa7jl2RKFXj5BRL31ztQuqVQ4VlCiVbZFvje > aipBL8p1l9EBdEUdQIM7tnykeP9EY+0F5zQmSqAuxxk+CFKQZBJ2FqZN1bnvi5OC > QQFaUy4sGQKdI/uoOQOVM5YHXzQxJ6tZY1zFUudQwcs/Sdi2EQkRZQVOpMHeeqQ= > =dI3t > -----END PGP SIGNATURE----- > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From alexanderino at gmail.com Sat Nov 22 09:47:53 2014 From: alexanderino at gmail.com (Jason Antony) Date: Sat, 22 Nov 2014 19:47:53 +1100 Subject: Symmetrical encryption or ... In-Reply-To: References: <546FF6CF.3080400@dougbarton.email> Message-ID: <54704DB9.6050102@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-22 18:54, Dave Pawson wrote: > I installed keepassx. Not much use to me. 1. Illegible with my > eyesight (reported to them) 2. Insufficient fields (seems to be non > expandable). Try Keepass2 (official). It worked fine for me when I last used Linux, and requires the Mono runtime. Fonts are adjustable, and the auto-type (requires the xdotool package for Linux) will fulfil the wishes you had stated earlier. All the best, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUcE22AAoJED1Q2DsLuMaGC9oQAIRgnf0bZ5/m1ZADwkLMe9GV 6pytc9ThExmRFUYNstHOdl7UHY+dgXzIvhszcyZsSDAMLG2zHrdIuWEoud429qol 6Mu7Xp44wQfmlqMCPi7zX69YgnZo2E/I5Wwi10hPhcy80UGprkilMbHl9DrR6m5q 40nFas6FQG6dOG6OHZPizUc7JI6/bdJhH0NxLoBnSynoqvsnEQvpDnufzXqQZRUa GYV5n0pO3OUPTXSWxtJKWVWdNdUQGe+16pyPPdrc+7WLJkFGQ42ZxxxQYTTskt+M IFnJu8QnQ31vn0ydpia7cagOYvYohPfkai84rFHNEioeKY5JUsS3N3u9l4j0NM5Q 6howXRnxINfKZ3u0XrEEvXBiZy6jBFwfeofqrGGLveP2HuaLxRDhjpmhJqdad4VK Ccc/4B0CYFNMi4sYctKGEd83MYQdDNu4+4XJWbgVrddsxQXbrks6GBwv7q7aSoif SUCasJwZHK9xa2OWoSUixlkmZ9TwviixphbagvulABmaW0JIAux9o7CwnxfvRf2r SLm5mXQIY3L9f3iX/gqwXiBjrMNk4mOKutAJel2DcKWDa+3kh6mlWHMKxD9uYi6c E3Hvg26XI2fe+cjJ87nyMGrxGdK/8BEHJKAs02tCK7af3plCcqd+nUhpP8cspM2A u3pLdGRT4dMI4NdiNSM6 =VeTD -----END PGP SIGNATURE----- From dave.pawson at gmail.com Sat Nov 22 10:23:37 2014 From: dave.pawson at gmail.com (Dave Pawson) Date: Sat, 22 Nov 2014 09:23:37 +0000 Subject: Symmetrical encryption or ... In-Reply-To: <54704DB9.6050102@gmail.com> References: <546FF6CF.3080400@dougbarton.email> <54704DB9.6050102@gmail.com> Message-ID: https://launchpad.net/ubuntu/+source/keepass2 Looks like Ubuntu only? Not found for Fedora. I'll stick with symmetric for now. Thanks Jason On 22 November 2014 08:47, Jason Antony wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2014-11-22 18:54, Dave Pawson wrote: > >> I installed keepassx. Not much use to me. 1. Illegible with my >> eyesight (reported to them) 2. Insufficient fields (seems to be non >> expandable). > > Try Keepass2 (official). It worked fine for me when I last used Linux, > and requires the Mono runtime. Fonts are adjustable, and the auto-type > (requires the xdotool package for Linux) will fulfil the wishes you > had stated earlier. > > All the best, > > Jason > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJUcE22AAoJED1Q2DsLuMaGC9oQAIRgnf0bZ5/m1ZADwkLMe9GV > 6pytc9ThExmRFUYNstHOdl7UHY+dgXzIvhszcyZsSDAMLG2zHrdIuWEoud429qol > 6Mu7Xp44wQfmlqMCPi7zX69YgnZo2E/I5Wwi10hPhcy80UGprkilMbHl9DrR6m5q > 40nFas6FQG6dOG6OHZPizUc7JI6/bdJhH0NxLoBnSynoqvsnEQvpDnufzXqQZRUa > GYV5n0pO3OUPTXSWxtJKWVWdNdUQGe+16pyPPdrc+7WLJkFGQ42ZxxxQYTTskt+M > IFnJu8QnQ31vn0ydpia7cagOYvYohPfkai84rFHNEioeKY5JUsS3N3u9l4j0NM5Q > 6howXRnxINfKZ3u0XrEEvXBiZy6jBFwfeofqrGGLveP2HuaLxRDhjpmhJqdad4VK > Ccc/4B0CYFNMi4sYctKGEd83MYQdDNu4+4XJWbgVrddsxQXbrks6GBwv7q7aSoif > SUCasJwZHK9xa2OWoSUixlkmZ9TwviixphbagvulABmaW0JIAux9o7CwnxfvRf2r > SLm5mXQIY3L9f3iX/gqwXiBjrMNk4mOKutAJel2DcKWDa+3kh6mlWHMKxD9uYi6c > E3Hvg26XI2fe+cjJ87nyMGrxGdK/8BEHJKAs02tCK7af3plCcqd+nUhpP8cspM2A > u3pLdGRT4dMI4NdiNSM6 > =VeTD > -----END PGP SIGNATURE----- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk From alexanderino at gmail.com Sat Nov 22 11:10:40 2014 From: alexanderino at gmail.com (Jason Antony) Date: Sat, 22 Nov 2014 21:10:40 +1100 Subject: Symmetrical encryption or ... In-Reply-To: References: <546FF6CF.3080400@dougbarton.email> <54704DB9.6050102@gmail.com> Message-ID: <54706120.4040709@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-22 20:23, Dave Pawson wrote: > Not found for Fedora. It can be done for Fedora. You'll need to download the portable version of Keepass2 from the official website, and install the Mono runtimes and xdotool. After extracting the keepass2 archive, cd to the directory, then run: mono KeePass.exe Instructions found here: https://cloudplasma.co.uk/2014/01/keepass-2-fedora-20/ Regards, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUcGEfAAoJED1Q2DsLuMaGVO0QALaTvt2zP9SC2yZ+uqhbm/ko JYfjvxRVjT3FLEfA2sZ4NAVTHS/wO0qSW8F+jSjRyybW85A8mDJHgF0LSVcRzvcr qYYys1J8IohcfkBMfSXNUyfEvG2Dl2qoeryvKg1Ar1iDG8G1SAcHMoPgHdrgWCAb RmhdBR0QCMOEBbS+c/YKLowIcCvC/XRmvMEYBPStHHs1Lm6arbsysP4DpN3KSbZK kEjDSqbp7P0B7ghpkX1I0XNILt9GJ6CQaq0TB1riKrIaEPzl9VY8cLk7VgWGFboc A8AATZXMdp4+veijRtvYv8dwzb0Tsl5Kt2Q/JtoXTjMfy1lZTW3nCxromi2WJP0Z peZb5Ii7Mkw5p3HNLzzllM/fDSI3qNerdpp9oIyY7XG69ctrqz40u0hBpDa+RLXW ojKDu2h54npFXDF2r5006VZ4JEDuZwUH1ojqbhq6J/Luet8M4tpkg4hc38Gad9ay LEwpwNm5oAhWyt9JTOusYwtZUXQqF4iCr1SXllmkHBXUtLwXXwr82Ar+c9pOxMix EYyRhWGVVdtYSQQmdb3S6jpFjdhmOMLTWjIjU8xNM0TjhIiZ8AidFfsS0CWnXbAw wG0SCN/Q+c4icQiD5Mriwo2/KxGawj1aOdSKhLd9NBDLM7X86sZS3jy5QMnQNwBl 7Z7BhCsNupM82yyytby5 =n+6a -----END PGP SIGNATURE----- From peter at digitalbrains.com Sat Nov 22 11:11:07 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 22 Nov 2014 11:11:07 +0100 Subject: Symmetrical encryption or ... In-Reply-To: References: <546FF6CF.3080400@dougbarton.email> <54704DB9.6050102@gmail.com> Message-ID: <5470613B.6000907@digitalbrains.com> On 22/11/14 10:23, Dave Pawson wrote: > https://launchpad.net/ubuntu/+source/keepass2 > > Looks like Ubuntu only? > > Not found for Fedora. If I look at the KeePass website, specifically at [1], I see: ---------------- 8< -------------- >8 ---------------- In addition to Windows, KeePass 2.x runs fine under Mono, i.e. Linux, Mac OS X, BSD, etc. Links to all supported packages can be found on the KeePass downloads page: http://keepass.info/download.html. Debian/Ubuntu Linux: Install the keepass2 / KeePass 2.x for Debian/Ubuntu Linux package (e.g. using APT). A link to a page with more information about this package can be found on the downloads page. Fedora Linux: Install the keepass package (from the Fedora repository; link on the downloads page). [...] ---------------- 8< -------------- >8 ---------------- So it would appear that Fedora calls the package "keepass" rather than "keepass2", but it is available (and is actually version 2.x). I use KeePass 2 myself and like it. I only use Linux though. By the way, regarding your first post: while symmetric mode is pretty much invented for your use case, you can also encrypt to your own public key. It would be overkill if that is all you have the private key installed for. But if you have the private key installed anyway and use it for other stuff, and have gpg-agent cache your passphrase, it would mean you wouldn't have to type the passphrase every time. I can think of a special case where it gets even better in my eyes: if you have a smartcard. You only have to type a relatively short PIN instead of a strong passphrase. Then again, I type my KeePass 2 strong passphrase often enough, and it's not bothersome. Maybe I just like smartcards :). Yep, that's it. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sat Nov 22 11:17:24 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 22 Nov 2014 11:17:24 +0100 Subject: Symmetrical encryption or ... In-Reply-To: <5470613B.6000907@digitalbrains.com> References: <546FF6CF.3080400@dougbarton.email> <54704DB9.6050102@gmail.com> <5470613B.6000907@digitalbrains.com> Message-ID: <547062B4.9060608@digitalbrains.com> On 22/11/14 11:11, Peter Lebbing wrote: > If I look at the KeePass website, specifically at [1], I see: Whoops! [1] http://keepass.info/help/v2/setup.html#mono -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From patrick-mailinglists at whonix.org Fri Nov 21 21:17:38 2014 From: patrick-mailinglists at whonix.org (Patrick Schleizer) Date: Fri, 21 Nov 2014 20:17:38 +0000 Subject: Update existing key to ECC? Message-ID: <546F9DE2.6010700@whonix.org> Hi, is it possible to update an existing (RSA) gpg key to ECC? Or would a usual transition process be required? Cheers, Patrick From mailinglisten at hauke-laging.de Sat Nov 22 16:01:02 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 22 Nov 2014 16:01:02 +0100 Subject: Update existing key to ECC? In-Reply-To: <546F9DE2.6010700@whonix.org> References: <546F9DE2.6010700@whonix.org> Message-ID: <13001443.41m1GfcYW6@inno> Am Fr 21.11.2014, 20:17:38 schrieb Patrick Schleizer: > is it possible to update an existing (RSA) gpg key to ECC? > > Or would a usual transition process be required? You can change the subkeys (encryption, signing) easily but not the mainkey (the one the fingerprint refers to). But hardly any GnuPG out there can use ECC now. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 22 21:12:15 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 22 Nov 2014 20:12:15 +0000 Subject: Error message "Ohhhh jeeee: ... this is a bug" In-Reply-To: References: <629851038.20141115194527@my_localhost> <87ppcmqcyq.fsf@vigenere.g10code.de> <1417552682.20141118230805__8083.15750114179$1416352176$gmane$org@my_localhost> Message-ID: <123012723.20141122201215@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 19 November 2014 at 5:07:37 PM, in , Hugo Hinterberger wrote: > I just tried to verify your message, but failed at > importing your key. GPG tellst me that the key packet > is of an obsolete version 3. Do you have the key in a > newer format? Is it possible to import the old key > somehow? My key 0xA8A90B8EAD0C6E69 is an obsolete version 3 key and cannot be imported into GnuPG 2.1. That key will still work with GnuPG 1.4.x or 2.0.x. I do not have the key in a newer format, and have not yet investigated whether there is any useful way to achieve this. I understand it is possible to convert the same key material from an OpenPGP key to an X509 certificate and vice versa, so I presume it's technically possible to convert a v3 key to a v4 key. But I am not optimistic that such a converted key could be used to check signatures made by, or decrypt data encrypted to, the original v3 key. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net You're only young once; you can be immature forever -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRw7jVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pUlUEAIQoYxQn0jCWrcATAPM9My8hKlxChfdqd6Z/ Y5ah+e11ErFgkCT3zshYn9PA3BgPGLAPJpwcgf84ry5zu1j4iPt1+Y/Bie7Cxe5L 8UXmfTeJmdSE+yXw7RtTtPEaR9dC7DpIkb9TsVlt+Gj8oe2NZldkNBKjnrPZM6Yp tGmroax7iQF8BAEBCgBmBQJUcO41XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwoYkH/jHKV2CDnvsbaiEx xI5lpn38xh0OHYJ1rjH+wbYKUW6KzqMNIs18Mv+JujGJszmk1NLcqDdmD9GR8sPk 46UIEsY18afrh3G1jE4pNk7zjlqGoabAPyXn+idSt3G7Rv8Efj3bRrXfOAGlRV1a j6UkSlZX5jCBAsWoBnlR1l4MRX2mYW1amzWVJddZvEaeDwEBu8NPJZGfxWiDCiQ7 bLdeo4XRSMTUswURaDQxdCS1Wj/67LVWY1RKWEuUiawnqrC8vQ55Rg0qW4fXNKet MzeVjdG/4ZLNV19AVxosWVnpk4vr9Zu7sSsO+YiuNhqcs7hyPk/1e8GCJg9/7jPy K4RnbR4= =SPly -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 22 22:16:38 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 22 Nov 2014 21:16:38 +0000 Subject: Encryption on Mailing lists sensless? In-Reply-To: References: Message-ID: <145713323.20141122211638@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 19 November 2014 at 7:50:32 PM, in , MichaelQuigley at TheWay.Org wrote: > Which of course would not be possible if the public > mailing list was all encrypted. Unless the search engine subscribed to the encrypted list and produced search results in the clear. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net However beautiful the strategy, you should occasionally look at the results. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRw/TtXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p7DQEAIKc0KX9GOiNA8Hu/Vp0AT2zHOjVHWKecRbP uZWkhsY1m73aZJGgy54HdFhzslGwoZiePwlUxSmRSZsSId78XsXVjlNUZshadyMT uJZvo1IJw3rpqmzCt05bzD2G3BinxvIBwaf/HnOpgMvZK/ga7irq2aNdix3Mxm1K IslEsxbMiQF8BAEBCgBmBQJUcP07XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwd+wH/2ztQ9fvkVV9Ztkn tJmRJD+ELQCMn3z+M/Yhr62wzQbTkH3bFiczD6DwLQknhr21wS01CWT5Fh6uD97K vjWFfxs+PzVlBgdjIsQHo2kDMg5wnPyAdUBjWPa5RufhsOFbJMSKr4edZAzNe5bC GHvMA5de2mfHjPrjM5hm7LagRZzvCl5FLjsf3T6Cez0r+5m/kZY4AaRTk8FS8Mty u7PP/q8eTJEwzhgRq4aWUah+34rDKdn397v4vg5aPhS7FYVBMIU/mmsmJOsl37XC +k9x80dOnyEmAK4C2RnarBcLqFreboz4P8FmKuFDQlt4edGYOpaREFu+ClYoe4LE 7z9pKuQ= =qcVd -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 22 22:47:09 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 22 Nov 2014 21:47:09 +0000 Subject: Encryption on Mailing lists sensless? In-Reply-To: <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> <448302142.20141118224318@my_localhost> <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> Message-ID: <1796158353.20141122214709@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 20 November 2014 at 9:54:50 PM, in , Ingo Kl?cker wrote: > KMail encrypts an individual copy for each BCC > recipient. I thought Thunderbird+Enigmail would also > do this. I don't know how Thunderbird+Enigmail handles this. The app I was thinking of encrypted an individual copy for each recipient, be they a To, a CC or a BCC. > Any mail client not doing this completely subverts BCC > (unless --throw-keyids or --hidden-recipient is used, I agree. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Vegetarian: Indian word for lousy hunter!!! -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRxBGNXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p+H8EALMXRIHCXcNfC7TE05b5R0hgMRgkMkjTkXEH eCsgvs0SAL2ai4JKraDIw28rEhLtXjLrZftcjns9y2IrIlTmJgI6S3uiar3G8srX Eo6KbkPjD/kAzRzCbYoaW2DWV1PfLuqUeYtDxYeOM/V5ejo2U0HfblzfXQ+1KrIL CVAFYajEiQF8BAEBCgBmBQJUcQRjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwR5wH/0cNDfTmWZCf4hG3 ITs9jrQtTvAoNmqVCJDjkmdKTK0G0vY3bkw20uzkDVik1ju1O2c6irnmLlMbHrut 7efkeIfbchxhRGGZkZXM8UhTK2NE+G47o82UrdSeGuJwKxfLYFXyPlgZzzYj4GAl sz9VbErXqrCvyI0W8yl3bid8+zH1Mg2XEbbfJZh+j0xBa5A/0r/MTKkqUWSZYNYJ zcC9UJoxtx4f8HYeQP3Ixl2McRf8tOW2xuXFh2Idj79hH+uS1KRIfjMuOQpf6jO2 TSeEwXgTa8uXLrK4HGC1oMkKRrx9yKwpG1S9QhX0Jo+g8uN6gvPTJBfeJrH6gOM0 FiyR90I= =lwpN -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Sat Nov 22 23:14:47 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sat, 22 Nov 2014 22:14:47 +0000 Subject: Update existing key to ECC? In-Reply-To: <13001443.41m1GfcYW6@inno> References: <546F9DE2.6010700@whonix.org> <13001443.41m1GfcYW6@inno> Message-ID: <18810006491.20141122221447@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 22 November 2014 at 3:01:02 PM, in , Hauke Laging wrote: > You can change the subkeys (encryption, signing) easily > but not the mainkey (the one the fingerprint refers > to). But hardly any GnuPG out there can use ECC now. Newly-added ECC signing and encryption subkeys would be used in preference by GnuPG 2.1; older GnuPG versions would ignore them and use the older subkeys. And you can configure GnuPG 2.1 to sign with both signing subkeys (or just the older subkey, but then what's the point of the newer one?), so that contacts using older versions would be able to verify your signatures. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net After all is said and done, a lot more will be said than done. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlRxCt1XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pJsAD/ipid5eAcb1TEZCSmglkar11Hnp0s07WQVqI 7T9aUx/ypohX4sVi9tgt9PulXcOwESiXE7bP/RbN1yiFuaU2VjUGt+Y/88LNLXk/ F5uw3RSWCay54TyJYAQ4zw2GBKwjakx6sBmjU9OhzIHmWOKKOPakoifNRIUkv2bj /ry+rRyKiQF8BAEBCgBmBQJUcQrdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw1+IIAIFtqax3nSRRRPMq L2Pv/iK0G0E3kH+Ce8rAiqjqqImRHmjcqOyD2WnbCNiLP5T6V67ulOlARcH81e+j GF0hoMC3CRZQlOS5QFR3hFHbjkHnibdOdWrDHlECND1a1dJHKzEcvnpnSIk5GU2R JhW3B9OwwVOvwLVeuAtgaD2vKcgsnA0Y1C/nTHCi7OCfKBGXZUZTDVr/DFRUQg+2 Z6p2lYzCmGILCFCdzMC+kXURrp7zgTsYRJBdvVbrcXlOHvMvupPfv/yMNdjSfKQS v/8lwevW+icGkNIH0lE15QlO05S7FLXpLXA9QD3fr2fbr8IHWSutJH+y4tlXOrvl LCUb5xM= =Yphr -----END PGP SIGNATURE----- From bre at pagekite.net Sun Nov 23 14:12:47 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Sun, 23 Nov 2014 13:12:47 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? Message-ID: <20141123131247-16648-8407-mailpile@slinky> Hello gnupg-users! I am the lead dev on Mailpile, a free software e-mail client where we're doing our best to improve the usability of PGP-encrypted e-mail. I have been pondering for quite some time the relative merits of various ways of formatting otugoing encrypted mail, and this weekend I took the time to summarize my findings and opinions in a blog post: https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html The "tl;dr" is that it might be worth dropping PGP/MIME for outgoing encrypted mail and instead use a more ad-hoc approach which interoperates with more mail clients. I'm also tentatively proposing an approach to reducing the header metadata leakage (Subject, From, To, etc. being sent in the clear). Note that we already support incoming PGP/MIME and have no intention of abandoning that, it's merely a question of what is the best (default) format for outgoing encrypted mail. As folks on this list have been using GPG in the real world longer than most, I would very much appreciate your feedback, experience and opinions. Thanks! -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From rjh at sixdemonbag.org Sun Nov 23 16:09:30 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 23 Nov 2014 10:09:30 -0500 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141123131247-16648-8407-mailpile@slinky> References: <20141123131247-16648-8407-mailpile@slinky> Message-ID: <5471F8AA.6040205@sixdemonbag.org> > As folks on this list have been using GPG in the real world longer than > most, I would very much appreciate your feedback, experience and > opinions. This subject tends to get a lot of very passionate opinions on both sides. The FAQ covers both: https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime (ObDisclosure: I wrote this entry.) Until such time as the SMTP ecosystem improves and no longer mangles a significant fraction of PGP/MIME traffic, I think inline should be preferred where feasible. That's just my own opinion, though: take it for what it's worth. From samir at samirnassar.com Sun Nov 23 17:54:39 2014 From: samir at samirnassar.com (Samir Nassar) Date: Sun, 23 Nov 2014 18:54:39 +0200 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141123131247-16648-8407-mailpile@slinky> References: <20141123131247-16648-8407-mailpile@slinky> Message-ID: <1877445.2Xkiboyltq@forge> On Sunday, 2014-11-23 13:12:47 Bjarni Runar Einarsson wrote: > https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html > > The "tl;dr" is that it might be worth dropping PGP/MIME for outgoing > encrypted mail and instead use a more ad-hoc approach which > interoperates with more mail clients. I'm also tentatively proposing an > approach to reducing the header metadata leakage (Subject, From, To, > etc. being sent in the clear). I would care more about the arguments if you were able to re-state them while dropping references to legacy email clients. I don't think new mail clients have an obligation to be backwards compatible. If you, and others, think the PGP/MIME RFC is incomplete or invalid, then that's a conversation I want to hear. Samir -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From bre at pagekite.net Sun Nov 23 19:05:03 2014 From: bre at pagekite.net (=?utf-8?q?Bjarni_R=C3=BAnar_Einarsson?=) Date: Sun, 23 Nov 2014 18:05:03 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <1877445.2Xkiboyltq@forge> References: <1877445.2Xkiboyltq@forge> Message-ID: <20141123180431-16648-36061-mailpile@slinky> Hi Samir, Samir Nassar wrote: > I would care more about the arguments if you were able to re-state them > while dropping references to legacy email clients. I don't think new mail > clients have an obligation to be backwards compatible. > > If you, and others, think the PGP/MIME RFC is incomplete or invalid, > then that's a conversation I want to hear. Oh, I absolutely do. I think it's fundamentally lacking. Key points: 1) It tightly couples MIME parsing and PGP processing, making it hard to compose "does one thing well" type tools and requiring quite invasive plugin APIs in order for people to be able implement PGP/MIME from a plugin. 2) It is hard to implement correctly. The white-space handling particularly hairy. 3) It does not protect any of the RF2822 message header - it doesn't even verify the integrity of its contents. Flaws 1) and 2) are why we still keep seeing new mail applications written that do not support PGP/MIME, and still see PGP email projects that can't do it either. See Mailvelope, APG/K9, more. The developers of these projects are not lazy, the standard is just a pain in the ass to implement. I know, I've done it. Flaw 3) is one of the reasons why big chunks of the security community write off PGP and e-mail as a lost cause. This was touched on in my post and a alternate strategy for encrypting mail was suggested that does not have these flaws. I am disappointed that you think it's okay to just ignore real world compatibility and dismiss all the mail clients that don't implement PGP/MIME as "legacy". That's a very lonely ivory tower, and with that attitude our community will never help the masses communicate securely. Cheers, - Bjarni -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From nan at goodcrypto.com Sun Nov 23 20:43:14 2014 From: nan at goodcrypto.com (Nan) Date: Sun, 23 Nov 2014 19:43:14 GMT Subject: Pros and cons of PGP/MIME for outgoing e-mail? Message-ID: <20141123194314sKtkwDrZBu@goodcrypto.com> Hi Bjarni, Our choice was based on compatibility and reliability. For an outgoing encrypted message, if there's an attachment GoodCrypto sends PGP/MIME, otherwise PGP in the body. We decrypt both formats. Glad to hear Mailpile is in Beta. Good luck! Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works. From aixtools at gmail.com Sat Nov 22 16:46:29 2014 From: aixtools at gmail.com (Michael Felt) Date: Sat, 22 Nov 2014 16:46:29 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: Same question: who to submit bug too? libgcrypt is not compiling (all other pre-requistes are done). Thanks. "../src/mpi.h", line 292.16: 1506-343 (S) Redeclaration of _gcry_mpi_ec_set_mpi differs from previous declaration on line 423 of "../src/gcrypt-int.h". "../src/mpi.h", line 292.16: 1506-050 (I) Return type "enum {...}" in redeclaration is not compatible with the previous return type "unsigned int". "../src/mpi.h", line 294.16: 1506-343 (S) Redeclaration of _gcry_mpi_ec_set_point differs from previous declaration on line 425 of "../src/gcrypt-int.h". "../src/mpi.h", line 294.16: 1506-050 (I) Return type "enum {...}" in redeclaration is not compatible with the previous return type "unsigned int". "../src/mpi.h", line 299.16: 1506-343 (S) Redeclaration of _gcry_mpi_ec_new differs from previous declaration on line 418 of "../src/gcrypt-int.h". "../src/mpi.h", line 299.16: 1506-050 (I) Return type "enum {...}" in redeclaration is not compatible with the previous return type "unsigned int". make[2]: *** [mpi-add.lo] Error 1 make[1]: *** [all-recursive] Error 1 On Thu, Nov 6, 2014 at 10:01 AM, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a > new release: Version 2.1.0. > > The GNU Privacy Guard (GnuPG) is a complete and free implementation of > the OpenPGP standard as defined by RFC-4880 and better known as PGP. > > GnuPG, also known as GPG, allows to encrypt and sign data and > communication, features a versatile key management system as well as > access modules for public key directories. GnuPG itself is a command > line tool with features for easy integration with other applications. > A wealth of frontend applications and libraries making use of GnuPG > are available. Since version 2 GnuPG provides support for S/MIME and > Secure Shell in addition to OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > Three different versions of GnuPG are actively maintained: > > - GnuPG "modern" (2.1) is the latest development with a lot of new > features. This announcement is about the first release of this > version. > > - GnuPG "stable" (2.0) is the current stable version for general use. > This is what most users are currently using. > > - GnuPG "classic" (1.4) is the old standalone version which is most > suitable for older or embedded platforms. > > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. > > > What's New in GnuPG-2.1 > ======================= > > - The file "secring.gpg" is not anymore used to store the secret > keys. Merging of secret keys is now supported. > > - All support for PGP-2 keys has been removed for security reasons. > > - The standard key generation interface is now much leaner. This > will help a new user to quickly generate a suitable key. > > - Support for Elliptic Curve Cryptography (ECC) is now available. > > - Commands to create and sign keys from the command line without any > extra prompts are now available. > > - The Pinentry may now show the new passphrase entry and the > passphrase confirmation entry in one dialog. > > - There is no more need to manually start the gpg-agent. It is now > started by any part of GnuPG as needed. > > - Problems with importing keys with the same long key id have been > addressed. > > - The Dirmngr is now part of GnuPG proper and also takes care of > accessing keyserver. > > - Keyserver pools are now handled in a smarter way. > > - A new format for locally storing the public keys is now used. > This considerable speeds up operations on large keyrings. > > - Revocation certificates are now created by default. > > - Card support has been updated, new readers and token types are > supported. > > - The format of the key listing has been changed to better identify > the properties of a key. > > - The gpg-agent may now be used on Windows as a Pageant replacement > for Putty in the same way it is used for years on Unix as > ssh-agent replacement. > > - Creation of X.509 certificates has been improved. It is now also > possible to export them directly in PKCS#8 and PEM format for use > on TLS servers. > > A detailed description of the changes can be found at > https://gnupg.org/faq/whats-new-in-2.1.html . > > > Getting the Software > ==================== > > Please follow the instructions found at https://gnupg.org/download/ or > read on: > > GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found > at https://gnupg.org/mirrors.html . Note that GnuPG is not available > at ftp.gnu.org. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig > > This is the GnuPG 2.1 source code compressed using BZIP2 and its > OpenPGP signature. > > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig > > This is an experimental installer for Windows including GPA as > graphical key manager and GpgEX as an Explorer extension. Please > de-install an already installed Gpg4win version before trying this > installer. This binary version has not been tested very well, thus it > is likely that you will run into problems. The complete source code > for the software included in this installer is in the same directory; > use the suffix ".tar.xz" instead of ".exe". > > Although several beta versions have been released over the course of > the last years, no extensive public field test has been done. Thus it > is likely that bugs will show up. Please check the mailing list > archives and the new wiki https://wiki.gnupg.org for latest > information on known problems and workaround. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.0.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.0.tar.bz2.sig > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by one or more of the release signing keys. Make sure that > this is a valid key, either by matching the shown fingerprint > against a trustworthy list of valid release signing keys or by > checking that the key has been signed by trustworthy other keys. > See below for information on the signing keys. > > * If you are not able to use an existing version of GnuPG, you have > to verify the SHA-1 checksum. On Unix systems the command to do > this is either "sha1sum" or "shasum". Assuming you downloaded the > file gnupg-2.1.0.tar.bz2, you would run the command like this: > > sha1sum gnupg-2.1.0.tar.bz2 > > and check that the output matches the first line from the > following list: > > 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 > 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe > 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz > > > Release Signing Keys > ==================== > > To guarantee that a downloaded GnuPG version has not been tampered by > malicious entities we provide signature files for all tarballs and > binary versions. The keys are also signed by the long term keys of > their respective owners. Current releases are signed by one or more > of these four keys: > > 2048R/4F25E3B6 2011-01-12 > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048/E0856959 2014-10-29 > Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 > David Shaw (GnuPG Release Signing Key) > > rsa2048/33BD3F06 2014-10-29 > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa2048/7EFD60D9 2014-10-19 > Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 > Werner Koch (Release Signing Key) > > You may retrieve these files from the keyservers using this command > > gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ > 2071B08A33BD3F06 8A861B1C7EFD60D9 > > The keys are also available at https://gnupg.org/signature_key.html > and in the released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed using my standard PGP key. > > > Internationalization > ==================== > > This new branch of GnuPG has support for 4 languages: French, German, > Japanese, and Ukrainian. More translations can be expected with the > next point releases. > > > Documentation > ============= > > If you used GnuPG in the past you should read the description of > changes and new features at doc/whats-new-in-2.1.txt or online at > > https://gnupg.org/faq/whats-new-in-2.1.html > > The file gnupg.info has the complete user manual of the system. > Separate man pages are included as well but they have not all the > details available in the manual. It is also possible to read the > complete manual online in HTML format at > > https://gnupg.org/documentation/manuals/gnupg/ > > or in Portable Document Format at > > https://gnupg.org/documentation/manuals/gnupg.pdf . > > The chapters on gpg-agent, gpg and gpgsm include information on how > to set up the whole thing. You may also want search the GnuPG mailing > list archives or ask on the gnupg-users mailing lists for advise on > how to solve problems. Many of the new features are around for > several years and thus enough public knowledge is already available. > > > Support > ======= > > Please consult the archive of the gnupg-users mailing list before > reporting a bug . > We suggest to send bug reports for a new release to this list in favor > of filing a bug at . For commercial support > requests we keep a list of known service companies at: > > https://gnupg.org/service.html > > The driving force behind the development of GnuPG is the company of > its principal author, Werner Koch. Maintenance and improvement of > GnuPG and related software takes up most of their resources. To allow > him to continue this work he kindly asks to either purchase a support > contract, engage g10 Code for custom enhancements, or to donate money: > > https://gnupg.org/donate/ > > > Thanks > ====== > > We have to thank all the people who helped with this release, be it > testing, coding, translating, suggesting, auditing, administering the > servers, spreading the word, and answering questions on the mailing > lists. A final big Thank You goes to Hal Finney, who too early passed > away this year. Hal worked on PGP and helped to make OpenPGP a great > standard; it has been a pleasure having worked with him. > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > GNU Announcement mailing list > https://lists.gnu.org/mailman/listinfo/info-gnu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aixtools at gmail.com Sat Nov 22 16:30:42 2014 From: aixtools at gmail.com (Michael Felt) Date: Sat, 22 Nov 2014 16:30:42 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: <87ioisn1mo.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: Hello, I am looking into packaging gnupg-2.1.0 for AIX, and I know I need to package the other libraries as well. However, configure is reporting - in config.log that AIX does not have libiconv - which it does. So, my question is: to which gnu tool should I report a bug? This is, I assume, not a problem with gnupg itself, but the tools it uses to create the configure script. >From config.log: configure:11197: checking for iconv configure:11219: cc -o conftest -O2 -qlanglvl=extc99 -I/opt/include conftest.c >&5 ld: 0711-317 ERROR: Undefined symbol: .iconv_open ld: 0711-317 ERROR: Undefined symbol: .iconv ld: 0711-317 ERROR: Undefined symbol: .iconv_close ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. configure:11219: $? = 8 configure: failed program was: ... >From AIX: root at x064:[/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0]clear;nm /usr/lib/libiconv.a | grep iconv /usr/lib/libiconv.a[shr4.o]: ../../../../../../../src/bos/usr/ccs/lib/libiconv/ascii.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/ccsid.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/fcs.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/hcs.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/iconv.c f - ._iconvTable_Lower_exec t 740 ._iconvTable_close t 616 ._iconvTable_exec t 1480 .iconv T 2032 .iconv_close T 1836 .iconv_open T 2240 _iconvTable_Lower_exec d 40536 12 _iconvTable_Lower_exec d 41680 4 _iconvTable_close d 40560 12 _iconvTable_close d 41688 4 _iconvTable_exec d 40548 12 _iconvTable_exec d 41684 4 _iconv_ct_ett D 37952 812 _iconv_fold7_ett D 37136 812 _iconv_fold8_ett D 856 812 _iconv_host D 38768 432 iconv D 40572 12 iconv_close D 40512 12 iconv_open D 40584 12 /usr/lib/libiconv.a[shr.o]: ../../../../../../../src/bos/usr/ccs/lib/libiconv/ascii.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/ccsid.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/fcs.c f - ../../../../../../../src/bos/usr/ccs/lib/libiconv/hcs.c f - .__iconv_open T 0 ._iconvTable_Lower_exec t 824 ._iconvTable_close t 700 ._iconvTable_exec t 1564 .iconv T 2116 .iconv_close T 1920 .iconv_open T 2320 __iconv_open D 40512 12 _iconvTable_Lower_exec d 40536 12 _iconvTable_Lower_exec d 41692 4 _iconvTable_close d 40560 12 _iconvTable_close d 41700 4 _iconvTable_exec d 40548 12 _iconvTable_exec d 41696 4 _iconv_ct_ett D 37952 812 _iconv_fold7_ett D 37136 812 _iconv_fold8_ett D 856 812 _iconv_host D 38768 432 iconv D 40584 12 iconv32.c f - iconv_close D 40572 12 iconv_open D 40596 12 root at x064:[/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0] Thank you for your assistance, Michael On Thu, Nov 6, 2014 at 10:01 AM, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a > new release: Version 2.1.0. > > The GNU Privacy Guard (GnuPG) is a complete and free implementation of > the OpenPGP standard as defined by RFC-4880 and better known as PGP. > > GnuPG, also known as GPG, allows to encrypt and sign data and > communication, features a versatile key management system as well as > access modules for public key directories. GnuPG itself is a command > line tool with features for easy integration with other applications. > A wealth of frontend applications and libraries making use of GnuPG > are available. Since version 2 GnuPG provides support for S/MIME and > Secure Shell in addition to OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > Three different versions of GnuPG are actively maintained: > > - GnuPG "modern" (2.1) is the latest development with a lot of new > features. This announcement is about the first release of this > version. > > - GnuPG "stable" (2.0) is the current stable version for general use. > This is what most users are currently using. > > - GnuPG "classic" (1.4) is the old standalone version which is most > suitable for older or embedded platforms. > > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. > > > What's New in GnuPG-2.1 > ======================= > > - The file "secring.gpg" is not anymore used to store the secret > keys. Merging of secret keys is now supported. > > - All support for PGP-2 keys has been removed for security reasons. > > - The standard key generation interface is now much leaner. This > will help a new user to quickly generate a suitable key. > > - Support for Elliptic Curve Cryptography (ECC) is now available. > > - Commands to create and sign keys from the command line without any > extra prompts are now available. > > - The Pinentry may now show the new passphrase entry and the > passphrase confirmation entry in one dialog. > > - There is no more need to manually start the gpg-agent. It is now > started by any part of GnuPG as needed. > > - Problems with importing keys with the same long key id have been > addressed. > > - The Dirmngr is now part of GnuPG proper and also takes care of > accessing keyserver. > > - Keyserver pools are now handled in a smarter way. > > - A new format for locally storing the public keys is now used. > This considerable speeds up operations on large keyrings. > > - Revocation certificates are now created by default. > > - Card support has been updated, new readers and token types are > supported. > > - The format of the key listing has been changed to better identify > the properties of a key. > > - The gpg-agent may now be used on Windows as a Pageant replacement > for Putty in the same way it is used for years on Unix as > ssh-agent replacement. > > - Creation of X.509 certificates has been improved. It is now also > possible to export them directly in PKCS#8 and PEM format for use > on TLS servers. > > A detailed description of the changes can be found at > https://gnupg.org/faq/whats-new-in-2.1.html . > > > Getting the Software > ==================== > > Please follow the instructions found at https://gnupg.org/download/ or > read on: > > GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found > at https://gnupg.org/mirrors.html . Note that GnuPG is not available > at ftp.gnu.org. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig > > This is the GnuPG 2.1 source code compressed using BZIP2 and its > OpenPGP signature. > > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig > > This is an experimental installer for Windows including GPA as > graphical key manager and GpgEX as an Explorer extension. Please > de-install an already installed Gpg4win version before trying this > installer. This binary version has not been tested very well, thus it > is likely that you will run into problems. The complete source code > for the software included in this installer is in the same directory; > use the suffix ".tar.xz" instead of ".exe". > > Although several beta versions have been released over the course of > the last years, no extensive public field test has been done. Thus it > is likely that bugs will show up. Please check the mailing list > archives and the new wiki https://wiki.gnupg.org for latest > information on known problems and workaround. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.0.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.0.tar.bz2.sig > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by one or more of the release signing keys. Make sure that > this is a valid key, either by matching the shown fingerprint > against a trustworthy list of valid release signing keys or by > checking that the key has been signed by trustworthy other keys. > See below for information on the signing keys. > > * If you are not able to use an existing version of GnuPG, you have > to verify the SHA-1 checksum. On Unix systems the command to do > this is either "sha1sum" or "shasum". Assuming you downloaded the > file gnupg-2.1.0.tar.bz2, you would run the command like this: > > sha1sum gnupg-2.1.0.tar.bz2 > > and check that the output matches the first line from the > following list: > > 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 > 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe > 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz > > > Release Signing Keys > ==================== > > To guarantee that a downloaded GnuPG version has not been tampered by > malicious entities we provide signature files for all tarballs and > binary versions. The keys are also signed by the long term keys of > their respective owners. Current releases are signed by one or more > of these four keys: > > 2048R/4F25E3B6 2011-01-12 > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048/E0856959 2014-10-29 > Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 > David Shaw (GnuPG Release Signing Key) > > rsa2048/33BD3F06 2014-10-29 > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa2048/7EFD60D9 2014-10-19 > Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 > Werner Koch (Release Signing Key) > > You may retrieve these files from the keyservers using this command > > gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ > 2071B08A33BD3F06 8A861B1C7EFD60D9 > > The keys are also available at https://gnupg.org/signature_key.html > and in the released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed using my standard PGP key. > > > Internationalization > ==================== > > This new branch of GnuPG has support for 4 languages: French, German, > Japanese, and Ukrainian. More translations can be expected with the > next point releases. > > > Documentation > ============= > > If you used GnuPG in the past you should read the description of > changes and new features at doc/whats-new-in-2.1.txt or online at > > https://gnupg.org/faq/whats-new-in-2.1.html > > The file gnupg.info has the complete user manual of the system. > Separate man pages are included as well but they have not all the > details available in the manual. It is also possible to read the > complete manual online in HTML format at > > https://gnupg.org/documentation/manuals/gnupg/ > > or in Portable Document Format at > > https://gnupg.org/documentation/manuals/gnupg.pdf . > > The chapters on gpg-agent, gpg and gpgsm include information on how > to set up the whole thing. You may also want search the GnuPG mailing > list archives or ask on the gnupg-users mailing lists for advise on > how to solve problems. Many of the new features are around for > several years and thus enough public knowledge is already available. > > > Support > ======= > > Please consult the archive of the gnupg-users mailing list before > reporting a bug . > We suggest to send bug reports for a new release to this list in favor > of filing a bug at . For commercial support > requests we keep a list of known service companies at: > > https://gnupg.org/service.html > > The driving force behind the development of GnuPG is the company of > its principal author, Werner Koch. Maintenance and improvement of > GnuPG and related software takes up most of their resources. To allow > him to continue this work he kindly asks to either purchase a support > contract, engage g10 Code for custom enhancements, or to donate money: > > https://gnupg.org/donate/ > > > Thanks > ====== > > We have to thank all the people who helped with this release, be it > testing, coding, translating, suggesting, auditing, administering the > servers, spreading the word, and answering questions on the mailing > lists. A final big Thank You goes to Hal Finney, who too early passed > away this year. Hal worked on PGP and helped to make OpenPGP a great > standard; it has been a pleasure having worked with him. > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > GNU Announcement mailing list > https://lists.gnu.org/mailman/listinfo/info-gnu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun Nov 23 23:55:19 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 23 Nov 2014 23:55:19 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141123131247-16648-8407-mailpile@slinky> References: <20141123131247-16648-8407-mailpile@slinky> Message-ID: <3076219.DRMenkUREg@collossus.ingo-kloecker.de> On Sunday 23 November 2014 13:12:47 Bjarni Runar Einarsson wrote: > Hello gnupg-users! > > I am the lead dev on Mailpile, a free software e-mail client where we're > doing our best to improve the usability of PGP-encrypted e-mail. I have > been pondering for quite some time the relative merits of various ways > of formatting otugoing encrypted mail, and this weekend I took the time > to summarize my findings and opinions in a blog post: > > https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html > > The "tl;dr" is that it might be worth dropping PGP/MIME for outgoing > encrypted mail and instead use a more ad-hoc approach which > interoperates with more mail clients. How do you plan to encrypt multipart messages with "a more ad-hoc approach which interoperates with more mail clients"? PGP/MIME solves this problem in a standardized way that all mail clients that support PGP/MIME can handle. > I'm also tentatively proposing an > approach to reducing the header metadata leakage (Subject, From, To, > etc. being sent in the clear). Sender address and recipient address are part of the mail envelope. As long as you use SMTP there's not much point in trying to hide the From and the To header. OTOH, due to SMTP's nature simply putting some dummy email addresses into From and To is trivial. I just think that it serves no real purpose. Who do you want to hide the From and To headers from who does not have access to the mail envelope? Also, Werner Koch has mentioned several (?) times on this list that the obvious solution for this to attach the actual message to a wrapper message and encrypt the whole thing with PGP/MIME. Any fully MIME- and PGP/MIME- capable mail client will be able to decrypt and display such a message out-of- the-box. Regards, Ingo From kloecker at kde.org Mon Nov 24 00:27:12 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 24 Nov 2014 00:27:12 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141123180431-16648-36061-mailpile@slinky> References: <1877445.2Xkiboyltq@forge> <20141123180431-16648-36061-mailpile@slinky> Message-ID: <4145583.gamKRmn0aC@collossus.ingo-kloecker.de> On Sunday 23 November 2014 18:05:03 Bjarni R?nar Einarsson wrote: > Hi Samir, > > Samir Nassar wrote: > > I would care more about the arguments if you were able to re-state them > > while dropping references to legacy email clients. I don't think new mail > > clients have an obligation to be backwards compatible. > > > > If you, and others, think the PGP/MIME RFC is incomplete or invalid, > > then that's a conversation I want to hear. > > Oh, I absolutely do. I think it's fundamentally lacking. Key points: > > 1) It tightly couples MIME parsing and PGP processing, making it hard to > compose "does one thing well" type tools and requiring quite invasive > plugin APIs in order for people to be able implement PGP/MIME from a > plugin. Why? All it takes is one API call which takes a MIMETree and returns another MIMETree. > 2) It is hard to implement correctly. The white-space handling > particularly hairy. I don't understand what you mean. Do you refer to the removal of trailing white-space? What's hairy about that? > Flaws 1) and 2) are why we still keep seeing new mail applications > written that do not support PGP/MIME, and still see PGP email projects > that can't do it either. See Mailvelope, APG/K9, more. The developers of > these projects are not lazy, the standard is just a pain in the ass to > implement. I know, I've done it. So you've come to realize that writing an email client isn't all fun? Welcome to the real world. > Flaw 3) is one of the reasons why big > chunks of the security community write off PGP and e-mail as a lost > cause. The key of this statement is that they write off "e-mail as a lost cause" because this is unfixable in SMTP. The only solution is not to use SMTP. > I am disappointed that you think it's okay to just ignore real world > compatibility and dismiss all the mail clients that don't implement > PGP/MIME as "legacy". That's a very lonely ivory tower, and with that > attitude our community will never help the masses communicate securely. I'm sorry to disappoint you, but you won't help the masses communicate securely by writing yet another mail client. The masses won't use your mail client (or any other niche mail client). The public masses use Google mail, the corporate masses use Outlook/Exchange, and the smartphone masses use whatever mail client comes with their smartphone. If you want an achievable goal, then don't aim for the masses but for those people who really need means for secure communication. I expect those people to use PGP/MIME-capable mail clients (or no e-mail at all) and not some other mail clients with non-standard, homebrew encryption. Regards, Ingo From wk at gnupg.org Mon Nov 24 09:24:28 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 09:24:28 +0100 Subject: Beta for 2.1.1 available Message-ID: <87sih9gg5f.fsf@vigenere.g10code.de> Hi, mainly to test the fixes to the Windows installer, I did a quick beta last Friday. However, while testing it I found that in GPA the export of keys to the keyserver does still not work. Instead of delaying a test release even more I have published that installer anyway. Thus most things should be fixed and the Windows version should be usable from the command line, via GPA, and in the explorer. Of course there are still open bugs and I continue to work on them. The installer has a new graphics on the welcome page but it is a pretty stupid one. If someone has the talents creating a nice one, we could include that in the next release [1]. To not bother the mirros with this test release the files are in my scratch directory (and will eventually be removed): 1. The installer: ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.exe ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.exe.sig 2. The complete but large sources including all GTK+ stuff to comply with the GPL: ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.tar.xz ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.tar.xz.sig 3. A proper GnuPG source tarball: ftp://ftp.gnupg.org/people/werner/scratch/gnupg-2.1.1-beta35.tar.bz2 ftp://ftp.gnupg.org/people/werner/scratch/gnupg-2.1.1-beta35.tar.bz2.sig Checksums: ec1443da83dff4648cc73deb34113f8a8f261791 gnupg-w32-2.1.1-beta35_20141121.exe 9bca63c32bb06abe9b501d1464a65ccdb82a71b1 gnupg-w32-2.1.1-beta35_20141121.tar.xz f57dc5c21e118f7d4289137e2a6a08ab6e877e91 gnupg-2.1.1-beta35.tar.bz2 Bug reports please to the gnupg-users. GnuPG changes in 2.1.1-beta35 ----------------------------- * gpg: Detect faulty use of --verify on detached signatures. * gpg: New import option "keep-ownertrust". * gpg: Fixed regression in --refresh-keys. * gpg: Fixed best matching hash algo detection for ECDSA and EdDSA. * gpg: Improved perceived speed of secret key listisngs. * gpg: Print number of skipped PGP-2 keys on import. * gpgconf --kill does not anymore start a service only to kill it. * Fixed keyserver access for Windows. * Fixed build problems on Mac OS X * The Windows installer does now install development files * More translations (but most of them are not complete). GPA in version 0.9.6 (2014-11-21) ---------------------------------- * Support keyserver operations for GnuPG 2.1. [But send keys does not yet work] * Implement the IMPORT_FILES server command. * New "Refresh Key" action in the key manager's context menu. Note that in GPA's settings dialo there is no more list of keyservers. This is now configured in the Backend Preferences under the GPG tab because it uses the GPG directly. Salam-Shalom, Werner [1] This should be a 164 x 314 x 8 colors, no transparency and white background. I can convert it to the required Windows format. The GnuPG logo master and variants of it can be found at: -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: From bernhard at intevation.de Mon Nov 24 10:01:28 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Nov 2014 10:01:28 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141123131247-16648-8407-mailpile@slinky> References: <20141123131247-16648-8407-mailpile@slinky> Message-ID: <201411241001.38899.bernhard@intevation.de> Bjarni, On Sunday 23 November 2014 at 14:12:47, Bjarni Runar Einarsson wrote: > https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html thanks for working on Free Software and for discussing questions like this in the open! > Note that we already support incoming PGP/MIME and have no intention of > abandoning that, it's merely a question of what is the best (default) > format for outgoing encrypted mail. The short answer (from someone that was in the project team of S/MIME implementations for mutt and kmail and support for PGP/MIME for Kontact Mail and the Outlook plugin for Gpg4win (my roles did include technical coordination, analysis and testing.): I am on the PGP/MIME side of things, I recommend it as default for sending out emails. See also http://wiki.gnupg.org/SignatureHandling . a) for encrypted emails, there is no drawback. Every email client just have to be able to deal with message/rfc822 mime-parts anyway. b) for signatures, https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime lists the drawback that some transport agents will modify attachments. In the past I've published a number of patches and problem reports to Mailman, so I know this issue quite a bit. It is due to a missdesign of the python email package and it should be fixed. (And it is fixable by a reasonable effort). Another drawback is that some proprietary email clients (like outlook) do not enable someone to influence the mime-structre. This is the bigger issue of course. On the other hand, the advantages are clear and PGP/MIME seems the best design given current standards and practure of SMTP and MIME. And given a reasonable mime library, the implementation for creation is much easier as for parsing and should not pose a major problem. Best Regard, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bre at pagekite.net Mon Nov 24 10:25:43 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 24 Nov 2014 09:25:43 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <201411241001.38899.bernhard@intevation.de> References: <201411241001.38899.bernhard@intevation.de> Message-ID: <20141124092453-16648-55173-mailpile@slinky> Hi Bernhard, Bernhard Reiter wrote: > > thanks for working on Free Software and for discussing questions > like this in the open! And thank you for the friendly reply. :-) > The short answer (from someone that was in the project team of S/MIME > implementations for mutt and kmail and support for PGP/MIME for Kontact > Mail and the Outlook plugin for Gpg4win (my roles did include technical > coordination, analysis and testing.): > > I am on the PGP/MIME side of things, I recommend it as default for > sending out emails. See also http://wiki.gnupg.org/SignatureHandling . > > a) for encrypted emails, there is no drawback. Every email client just > have to be able to deal with message/rfc822 mime-parts anyway. I actually disagree, the drawbacks are significant if you broaden the scope to include users of mail clients that do not have native support - which once you step out of the Free Software bubble, is most mail clients. As discussed in my post, if you have a PGP key but are unable to use a PGP/MIME aware mail client for whatever reason (work supplied laptop, no Internet outside of Internet caf?s etc.), then you will not easily be able to receive and decrypt PGP/MIME attachments, even if you have GnuPG installed, because if you download the raw encrypted payload for processing offline, then after decryption you end up with a fragment of MIME and tools for working with such fragments barely exist outside the world of development tools (downloading the raw message source and manually feeding that to mutt, after manually adding the leading 'From ' delimiter is absolutely possible, but is not something you can expect a normal user to do, and not something a techie would enjoy doing on a regular basis). If this is carried to its logical conclusion, a burden ends up being placed on the user of a PGP/MIME enabled mail client - he has to carry around in his head a mental model of the technical capabilities of those receiving encrypted mail and *manually* change the format of his outgoing mail if he wants it to be readable by less technically privileged recipients. All in all, this goes way beyond what I consider an acceptable user experience. Of course, today encryption is so rare that the only folks encountering this problem are nontechnical people, journalists and activists and the like, and they just give up and us something else to communicate and we don't hear from them again. This issue came to my attention however, due to the rise of webmail and attempts to write plugins to communicated using PGP (although Javascript is getting so powerful, they are likely to overcome this in the near future, with a select few compatible webmail services), and I'm told this is also what happened with the K9 mail client and APG. I'd like Mailpile users to be able to easily exchange secure content with these users, even if their tools are a bit on the primitive side. I will however freely admit that I am not a veteran of the PGP encryption field. I've worked with it off and on for the past 20 years, but Mailpile is my first serious attempt at implementing a full stack. So perhaps I am overestimating the impact here? > b) for signatures, https://www.gnupg.org/faq/gnupg-faq.html#use_pgpmime > lists the drawback that some transport agents will modify attachments. In the > past I've published a number of patches and problem reports to Mailman, so I > know this issue quite a bit. It is due to a missdesign of the python email > package and it should be fixed. (And it is fixable by a reasonable effort). Yes, Mailpile is written in Python and I've had to bend over backwards in order to validate and generate signatures. I am pretty sure I still have bugs to work out there, trying to compensate for the Python library's flaws without rewriting the whole thing is, long term, a losing game. It is tempting to blame the Python libraries, but the fact is that they do generate valid MIME - after swearing at Python for months, it dawned on me that it's probably the PGP/MIME standard that is just being too picky. This is part of what I meant by tightly coupled in a previous e-mail - unless MIME libraries and interfaces are explicitly written with PGP/MIME in mind, and carefully tested, they easily end up being incompatible. MIME is a forgiving standard, PGP/MIME is emphatically not. This causes headaches for people trying to implement PGP/MIME and any source of friction like this reduces tool support and uptake. > Another drawback is that some proprietary email clients (like outlook) > do not enable someone to influence the mime-structre. This is the bigger issue > of course. Exactly. > On the other hand, the advantages are clear and PGP/MIME seems the best > design given current standards and practure of SMTP and MIME. And given a > reasonable mime library, the implementation for creation is much easier as for > parsing and should not pose a major problem. In my experience both generating and validating PGP/MIME signatures is very error prone if you are saddled with a MIME library that has different ideas about things. You are right, it is the best standard we've got at the moment, but only by virtue of being the ONLY standard we've got. All the other issues aside, I don't think anyone will seriously argue that an e-mail encryption standard which transmits the subject line in the clear is a "good standard". It's silly and we can do better. So really, I guess I'm asking this community for feedback on two things: 1) Are these problems as common as my experiences imply, or am I just really unlucky? 2) Is there any interest in trying to improve the standards? -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 24 10:55:45 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 24 Nov 2014 10:55:45 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <87sih9gg5f.fsf@vigenere.g10code.de> References: <87sih9gg5f.fsf@vigenere.g10code.de> Message-ID: <547300A1.7050301@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/2014 09:24 AM, Werner Koch wrote: > Hi, > > mainly to test the fixes to the Windows installer, I did a quick > beta last Friday. However, while testing it I found that in GPA > the export of keys to the keyserver does still not work. Instead > of delaying a Is this limited to GPA? I seem to also encounter issues directly from CLI to this effect. $ gpg --version gpg (GnuPG) 2.1.1-beta35 libgcrypt 1.7.0-beta113 $ gpg --send-key 0x0B7F8B60E3EDFAE3 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: sending key 0x0B7F8B60E3EDFAE3 to hkp server 192.168.0.33 Aborted 2014-11-24 10:52:40 dirmngr[29131.0] assuan_inquire failed: End of file 2014-11-24 10:52:40 dirmngr[29131.0] command 'KS_PUT' failed: End of file 2014-11-24 10:52:40 dirmngr[29131.0] Assuan processing failed: Broken pipe libassuan version is 2.1.2. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Timendi causa est nescire The cause of fear is ignorance -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUcwCgAAoJEPw7F94F4TagXIsQAKx3YHTVIK9H7+48FK3J+zxM Y7aE+VYoKm5p141/0maZsAWH+F/DdSDz93uGqoXMf7DaUA1ZxU3wI7ZsWyTePcLr EmySx5+5+emM9RmkM6j4neL1jfEH+fkrfx1ftCRPhEdCxLiQzVsjPPzRk5GiYuig Ktdz5ewBgjN7hlyNwCULPJIla61i5gEOPW7xPruMnUPlLsD98E8CfkFuTPQaWL54 plllZTp59E76POqeDGTEfAqqZaNyTWdOfpRNFVF1xHota8cEIef76duGH/Bd7AAb fvK2+LPEmg7OxwWsyChUM+0wZYMQTjTbnSWMePk7zYFRTaZurMNzcIyZCcwD+yDb WsJYy1KCNDFyqJALZXxgpCpT5q/S/Nompe1EzS3DTuSW7xbDjIG25tkinlTRJfAz b5gZgvUhumSpgGfNGZ/euQl+3T87Mzge9oXyHcBmmTDt1eEoOREnenq+6BTlw1V8 7lk+hQ4NYfldSouC8ol1Yy4lZfVoaFIqFuxTS4IkTjA0FuAd7TmK2RTc8ClUrm63 2YkMcvqCZaOeIe0A531XiucVPrCQo1vXYMt2qii+aoXN6NmkclnikHyXWQwMU/TW 1ZLVvZzrXPD6hA2NGmF/KkOgOdVIZBope79Y07//Iqu/Y/B4s7+Pwzs4sy3bPvV6 RTGhCmyNZ4x3yASEO4lg =cDWV -----END PGP SIGNATURE----- From wk at gnupg.org Mon Nov 24 12:31:12 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 12:31:12 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: (Michael Felt's message of "Sat, 22 Nov 2014 16:46:29 +0100") References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <87h9xog7i7.fsf@vigenere.g10code.de> On Sat, 22 Nov 2014 16:46, aixtools at gmail.com said: > Same question: who to submit bug too? http://bugs.gnupg.org but posting here is also okay. > "../src/mpi.h", line 292.16: 1506-343 (S) Redeclaration of > _gcry_mpi_ec_set_mpi differs from previous declaration on line 423 of > "../src/gcrypt-int.h". Oh what picky. We have gpg_err_code_t foo () and gpg_error_t foo () The first is an enum and the second is an unsigned int. According to Since the compiler treats enumeration variables and constants as integer types, you can freely mix the values of different enumerated types, regardless of type compatibility. Compatibility between an enumerated type and the integer type that represents it is controlled by compiler options and related pragmas. So it should not complain. However, this showed that there is some cruft in the headers. I fixed that in master. You may remove the duplicated prototypes from src/gcrypt-int.h. Something like: --- a/src/gcrypt-int.h +++ b/src/gcrypt-int.h @@ -416,15 +416,10 @@ gcry_mpi_point_t _gcry_mpi_point_set (gcry_mpi_point_t point, gcry_mpi_point_t _gcry_mpi_point_snatch_set (gcry_mpi_point_t point, gcry_mpi_t x, gcry_mpi_t y, gcry_mpi_t z); -gpg_error_t _gcry_mpi_ec_new (gcry_ctx_t *r_ctx, - gcry_sexp_t keyparam, const char *curvename); + gcry_mpi_t _gcry_mpi_ec_get_mpi (const char *name, gcry_ctx_t ctx, int copy); gcry_mpi_point_t _gcry_mpi_ec_get_point (const char *name, gcry_ctx_t ctx, int copy); -gpg_error_t _gcry_mpi_ec_set_mpi (const char *name, gcry_mpi_t newvalue, - gcry_ctx_t ctx); -gpg_error_t _gcry_mpi_ec_set_point (const char *name, gcry_mpi_point_t newvalue, - gcry_ctx_t ctx); int _gcry_mpi_ec_get_affine (gcry_mpi_t x, gcry_mpi_t y, gcry_mpi_point_t point, mpi_ec_t ctx); void _gcry_mpi_ec_dup (gcry_mpi_point_t w, gcry_mpi_point_t u, gcry_ctx_t ctx); Does this help? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 12:51:42 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 12:51:42 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: (Michael Felt's message of "Sat, 22 Nov 2014 16:30:42 +0100") References: <87ioisn1mo.fsf@vigenere.g10code.de> Message-ID: <87d28cg6k1.fsf@vigenere.g10code.de> On Sat, 22 Nov 2014 16:30, aixtools at gmail.com said: > However, configure is reporting - in config.log that AIX does not have > libiconv - which it does. So, my question is: to which gnu tool should I Well, the code does not detect it or it is not usable. The latter should be reported. The detection code is source copied in GnuPG and used to create the configure script. Some parts have not been updated for a long time and thus it might help to update them. Can you send me the complete config.log by private mail? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 12:52:53 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 12:52:53 +0100 Subject: Error message "Ohhhh jeeee: ... this is a bug" In-Reply-To: <123012723.20141122201215@my_localhost> (MFPA's message of "Sat, 22 Nov 2014 20:12:15 +0000") References: <629851038.20141115194527@my_localhost> <87ppcmqcyq.fsf@vigenere.g10code.de> <1417552682.20141118230805__8083.15750114179$1416352176$gmane$org@my_localhost> <123012723.20141122201215@my_localhost> Message-ID: <878uj0g6i2.fsf@vigenere.g10code.de> On Sat, 22 Nov 2014 21:12, 2014-667rhzu3dc-lists-groups at riseup.net said: > I do not have the key in a newer format, and have not yet investigated > whether there is any useful way to achieve this. I understand it is No, you can't convert the key to v4 format. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 13:28:01 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 13:28:01 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141123131247-16648-8407-mailpile@slinky> (Bjarni Runar Einarsson's message of "Sun, 23 Nov 2014 13:12:47 -0000") References: <20141123131247-16648-8407-mailpile@slinky> Message-ID: <871tosg4vi.fsf@vigenere.g10code.de> Hi Bjarni, On Sun, 23 Nov 2014 14:12, bre at pagekite.net said: > https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html Not read (yet). > The "tl;dr" is that it might be worth dropping PGP/MIME for outgoing > encrypted mail and instead use a more ad-hoc approach which Please don't do this. In particular the encrypted format is so easy to create and parse that it is not worth to even think about it. Yes, there are two MIME parts but you can ignore the first part and it is even possible to decrypt such a simple mail without any MIME knowledge. Creating is even easier, you can use a hard wired boundary. Signing is a bit more complete but for years there is no problem with such mails anymore - all MUAs are able to display the text and those not capable of PGP/MIME ignore the signature. I would suggest to ignore the micalg parameter - use pgp-sha1 if you create one but do not compare it when reaading. > interoperates with more mail clients. I'm also tentatively proposing an > approach to reducing the header metadata leakage (Subject, From, To, > etc. being sent in the clear). Wrap in a message/rfc822 part. > As folks on this list have been using GPG in the real world longer than > most, I would very much appreciate your feedback, experience and It has always been a heated discussion for close to 20 years. The non-US people mostly preferring PGP/MIME and the US people clear text signatures. Even S/MIME has meanwhile completely moved away from opaque signatures. Thus by supporting PGP/MIME you only need one framework and no alien stuff like PGP cleartext signed messages without the ability to attach something. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 13:43:09 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 13:43:09 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <547300A1.7050301@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 24 Nov 2014 10:55:45 +0100") References: <87sih9gg5f.fsf@vigenere.g10code.de> <547300A1.7050301@sumptuouscapital.com> Message-ID: <87tx1oeplu.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 10:55, kristian.fiskerstrand at sumptuouscapital.com said: > Is this limited to GPA? I seem to also encounter issues directly from > CLI to this effect. Yes. The thing is that GPA makes direct use of the gpgkeys_foo helpers and bypasses gpg for keyserver access. Now with 2.1 we do not have the gpgkeys_foo helpers anymore and thus export must go through gpg. This is not a big problem, given that GPGME support this for quite some time now. You problem must be a different one. $ ../g10/gpg2 --send-key 0x0B7F8B60E3EDFAE3 gpg: WARNING: unsafe permissions on homedir '/home/wk/b/gnupg/tmp' gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: sending key E3EDFAE3 to hkp server zimmermann.mayfirst.org $ grep zimmerman *conf gpg.conf:keyserver hkp://zimmermann.mayfirst.org > 2014-11-24 10:52:40 dirmngr[29131.0] assuan_inquire failed: End of file > 2014-11-24 10:52:40 dirmngr[29131.0] command 'KS_PUT' failed: End of file gpg died after sending the command to dirmngr? Add --debug 1024 to the gpg invocation to check this. > libassuan version is 2.1.2. Mine is 2.1.3 but the changes are only for Windows. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bre at pagekite.net Mon Nov 24 13:44:31 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 24 Nov 2014 12:44:31 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <871tosg4vi.fsf@vigenere.g10code.de> References: <871tosg4vi.fsf@vigenere.g10code.de> Message-ID: <20141124124407-16648-6736-mailpile@slinky> Hi Werner! Werner Koch wrote: > Hi Bjarni, > > On Sun, 23 Nov 2014 14:12, bre at pagekite.net said: > > > https://www.mailpile.is/blog/2014-11-21_To_PGP_MIME_Or_Not.html > > Not read (yet). > > > The "tl;dr" is that it might be worth dropping PGP/MIME for outgoing > > encrypted mail and instead use a more ad-hoc approach which > > Please don't do this. Since you haven't read the post, you don't know what I am proposing. So why would you say this? :-P > In particular the encrypted format is so easy to create and parse that it is not worth to even think about it. This is demonstrably incorrect, I have given numerous examples of mail clients and plugins that fail to accomplish this supposedly simple task. > > interoperates with more mail clients. I'm also tentatively proposing an > > approach to reducing the header metadata leakage (Subject, From, To, > > etc. being sent in the clear). > > Wrap in a message/rfc822 part. If PGP/MIME had proposed this from the start, then I wouldn't be able to make cheap shots about Subject lines and indeed, living with the other problems would be far more palatable. But PGP/MIME missed that boat, and the user experience of a message/rfc822 part inside a multipart encrypted wrapper is really not acceptable in today's clients. You wouldn't want to read all your incoming mail that way. Also consider that desktop users who don't have a PGP/MIME capable e-mail client installed, probably don't have user friendly tools for handling raw e-mail data either. So this doesn't help compatibility. It's better than the fragments of MIME we get today, but still not great. Note that I am very specifically exploring whether there are ways to interact better with the clients we have today. I'm not feeling much enthusiasm from the community though, mostly push-back. I'll admit I am disappointed, but it's useful feedback all the same. No matter how much thought I put into the proposal, if the community isn't interested then I should probably focus on other things. Thanks for taking the time! - Bjarni -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From wk at gnupg.org Mon Nov 24 14:12:48 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 14:12:48 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124092453-16648-55173-mailpile@slinky> (Bjarni Runar Einarsson's message of "Mon, 24 Nov 2014 09:25:43 -0000") References: <201411241001.38899.bernhard@intevation.de> <20141124092453-16648-55173-mailpile@slinky> Message-ID: <87ppcceo8f.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 10:25, bre at pagekite.net said: > installed, because if you download the raw encrypted payload for > processing offline, then after decryption you end up with a fragment of > MIME and tools for working with such fragments barely exist outside the > world of development tools (downloading the raw message source and There is also a good chance that you end up with QP or even Base64 encoded plaintext which you neither can't read using standard desktop tool. Now for the English world this is in general not a problem but most people do not use plain ASCII and thus most mails are QB or Base64 encoded and can't be read without proper MIME support or by Unix gurus. > manually feeding that to mutt, after manually adding the leading 'From ' formail is your friend ;-) > Of course, today encryption is so rare that the only folks encountering > this problem are nontechnical people, journalists and activists and the > like, and they just give up and us something else to communicate and we They are more clever that you probably expect. Copy+paste is a technique they use all the day and with that it is pretty easy to decrypt mail. Well plain ASCII of course because there is no standard on how to specify the character set - no the charset: armor header does not work. All the others users are using a modern MUAs anyway. > is that they do generate valid MIME - after swearing at Python for > months, it dawned on me that it's probably the PGP/MIME standard that is > just being too picky. Please explain that. RFC-3156 was released in 2001 to even relax some requirements of RFC-2015 (1996). Now compare that to the various problems with PGP-2 clear signed messages passing different gateways and systems - all kind of fun happened depending on the versions of PGP/GPG/FOO you used. RFC-3156 has a simple set of of requirements to help the trailing Tab/Space/CR problems. > This is part of what I meant by tightly coupled in a previous e-mail - > unless MIME libraries and interfaces are explicitly written with > PGP/MIME in mind, and carefully tested, they easily end up being All the problems I have seen with MIME were due to incomplete MIME implementations which barely worked ... and one which did ugly things to mails internally passing from one animal to the other. And no, the latter was not Outlook (which not claimed to be an RFC-822 aware mail client) > incompatible. MIME is a forgiving standard, PGP/MIME is emphatically > not. This causes headaches for people trying to implement PGP/MIME and It is related to encrypted - it can't be for signatures. The whole point of signatures is that you want to verify that the mail did not change. BTW, the standard practice in the industry seems to be encrypt the document and attach it. That is an easy to learn workflow and works identical to the way many companies send letter (e.g. PDF attached). >> Another drawback is that some proprietary email clients (like outlook) >> do not enable someone to influence the mime-structre. This is the bigger issue >> of course. > > Exactly. To be fair, that changed with Outlook 2010. We merely had not the resources to change GpgOL to make use of the new Outlook structure. > we've got. All the other issues aside, I don't think anyone will > seriously argue that an e-mail encryption standard which transmits the > subject line in the clear is a "good standard". It's silly and we can do The subject is not part of MIME. PGP/MIME is about MIME - it is not only used with RFC-821 and we can expect that SMTP will eventually replaced by a P2P protocol - conveying MIME containers. Anyway, the question is what you define as meta data: Only the addresses? The attention line/the subject? Good MUAs inform the user that the subject will be send in the clear and that can actually be good thing for fast scanning of mails. > 2) Is there any interest in trying to improve the standards? Counter question: Is there any interest in fixing the remaining non MIME capable MUAs? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bre at pagekite.net Mon Nov 24 14:24:01 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 24 Nov 2014 13:24:01 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <87ppcceo8f.fsf@vigenere.g10code.de> References: <87ppcceo8f.fsf@vigenere.g10code.de> Message-ID: <20141124132331-16648-17477-mailpile@slinky> Werner Koch wrote: > On Mon, 24 Nov 2014 10:25, bre at pagekite.net said: > > > is that they do generate valid MIME - after swearing at Python for > > months, it dawned on me that it's probably the PGP/MIME standard that is > > just being too picky. > > Please explain that. RFC-3156 was released in 2001 to even relax some > requirements of RFC-2015 (1996). Now compare that to the various > problems with PGP-2 clear signed messages passing different gateways and > systems - all kind of fun happened depending on the versions of > PGP/GPG/FOO you used. RFC-3156 has a simple set of of requirements to > help the trailing Tab/Space/CR problems. Hmm. I think some of the headaches I was having were caused by the Python MIME libraries giving me inconsistent serializations of the message parts, and not preserving the raw payload in others. I had to bypass the parser entirely in order to verify signatures. Maybe I was using the API wrong. I dunno. But that's exactly the point, if you don't implement your MIME parsing exactly right, PGP/MIME just fails horribly. Similarly, when generating messages I had to fork the Python lib's generator and disable various "helpful" hacks that were randomly mutating the behavior of the generator if it detected it was generating an encrypted message! > > This is part of what I meant by tightly coupled in a previous e-mail - > > unless MIME libraries and interfaces are explicitly written with > > PGP/MIME in mind, and carefully tested, they easily end up being > > All the problems I have seen with MIME were due to incomplete MIME > implementations which barely worked ... and one which did ugly things to > mails internally passing from one animal to the other. And no, the > latter was not Outlook (which not claimed to be an RFC-822 aware mail > client) > > > incompatible. MIME is a forgiving standard, PGP/MIME is emphatically > > not. This causes headaches for people trying to implement PGP/MIME and > > It is related to encrypted - it can't be for signatures. The whole > point of signatures is that you want to verify that the mail did not > change. You want to verify that the message composed by the user did not change - the technicalities of the container it is placed in could well have been considered out of scope. Requiring that white space placement and irrelevant things like boundary strings stayed unchanged is unnecessary and in practice counterproductive because it tightly couples parser/generator implementations with the security evaluation, leading to implementation difficulties and false positives. This is not helpful. False positives train users that security failures don't mean anything, and PGP/MIME seems designed to maximize such things. It would be far, far more useful to have a signature for each part so instead of a binary pass/fail, you get a more granular result saying "Message body was fine", "Attachment 2-5 are fine", and "Something (probably a mailing list) injected some foreign content". > BTW, the standard practice in the industry seems to be encrypt the > document and attach it. That is an easy to learn workflow and works > identical to the way many companies send letter (e.g. PDF attached). That is basically the kind of workflow my proposal emulates, is compatible with and attempts to improve upon. > Anyway, the question is what you define as meta data: Only the > addresses? The attention line/the subject? Good MUAs inform the user > that the subject will be send in the clear and that can actually be good > thing for fast scanning of mails. My proposal was to move any and all interesting headers into an encrypted (or merely signed) attachment I am calling a "manifest". You can think of it as an extended signature, that both protects the headers and provides a signature for each individual part of the message. That way it can validate contents and structure, and also transmit headers we would like to omit from the public RFC2822 header - without assuming or imposing anything about the low level technical structure of the MIME itself. This is a very low impact proposal which doesn't break compatibility with anything - you could even use it with PGP/MIME just to protect the message headers. But it has the potential to provide similar security benefits as PGP/MIME, without the implementation complexity and tight coupling. I even propose the format be human readable so people can do manual verification if they like. :-) > > 2) Is there any interest in trying to improve the standards? > > Counter question: Is there any interest in fixing the remaining non MIME > capable MUAs? Hah, you dodged the question. ;-) I'd love it if all the software got fixed. But even though improving standards is hard, I'm going to wager that this task is even harder. Cheers! - Bjarni -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 24 15:03:25 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 24 Nov 2014 15:03:25 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <87tx1oeplu.fsf@vigenere.g10code.de> References: <87sih9gg5f.fsf@vigenere.g10code.de> <547300A1.7050301@sumptuouscapital.com> <87tx1oeplu.fsf@vigenere.g10code.de> Message-ID: <54733AAD.2020208@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/2014 01:43 PM, Werner Koch wrote: > On Mon, 24 Nov 2014 10:55, > kristian.fiskerstrand at sumptuouscapital.com said: > >> Is this limited to GPA? I seem to also encounter issues directly >> from CLI to this effect. > ... > $ grep zimmerman *conf gpg.conf:keyserver > hkp://zimmermann.mayfirst.org $ grep -E "^keyserver" gpg.conf keyserver hkp://192.168.0.33 > >> 2014-11-24 10:52:40 dirmngr[29131.0] assuan_inquire failed: End >> of file 2014-11-24 10:52:40 dirmngr[29131.0] command 'KS_PUT' >> failed: End of file > > gpg died after sending the command to dirmngr? Add --debug 1024 to > the gpg invocation to check this. I reproduced this on a VM running $ gpg --version gpg (GnuPG) 2.1.1-beta40 libgcrypt 1.7.0-beta122 including --debug 1024 output log at: https://oc.sumptuouscapital.com/public.php?service=files&t=1d1b4f0b7b4c707c44cc388739ea5be9 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Timendi causa est nescire The cause of fear is ignorance -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUczqsAAoJEPw7F94F4TagMOkQAJlhLkv/4y8WJnSWISfWadMM BRplPAjVjqtKAA8O/OGKS6oJ9WZwZu8P5qrYGs1MNyeb3CEcSEyQSxBKyNhOVLhN ecuNIIekyMrcnJVgHKYw7v24vDOi8jA13A0x6brWwjYuFCknC946IHMyN/vr63X7 jfTxHbZ3K+7gNhgkC1J8M3GejjoVQqkC3gnR3PFJjebx6gPmEl0EK9atCocs5MRH q/LXlA4IMPPkmaqM2U1O6e9rIOsZyrmhmxlA4ZGKfg+FqfMiUU/nqrgmQIwRXr6A oN1vWDiv95ed6+BVZUkAWyuKU4S9uaRpJvVn+KV/h5iyL9LeszI6GGJ9RnaVLYVe 6Q+hYUEniIYfVbMOSvJakTQfinwe7AW7dYDbECYKc5zADb0mJM5+OHz1KMXSZAb/ yVu/hO0IzhBLgKZ9ARJtZqeBgEiuy/yMfa28iyuY1nrc/cc98zTwGtc+uiwwahUg ywMzLCMS4z62gzS7tMUoOi/L+jQJwXiJlLvEhopXHx05SE6KOxafP4yPoxbOnHVo PutHk6XuNXL4y482AEL7AOKWTchlCGk2D1XOmT15NGecgrDdGioLHP4NKLacC22E ehYzvcqYvQ3Geq4e5qjLhimZqUs+W7yzqsL+Qo+NRhyoOAYjlby0zkv/1RlhE8qf OLTJRQeZLpX2Hk/ViJ/F =4baA -----END PGP SIGNATURE----- From wk at gnupg.org Mon Nov 24 16:01:01 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 16:01:01 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <54733AAD.2020208@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 24 Nov 2014 15:03:25 +0100") References: <87sih9gg5f.fsf@vigenere.g10code.de> <547300A1.7050301@sumptuouscapital.com> <87tx1oeplu.fsf@vigenere.g10code.de> <54733AAD.2020208@sumptuouscapital.com> Message-ID: <87egssej82.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 15:03, kristian.fiskerstrand at sumptuouscapital.com said: > I reproduced this on a VM running $ gpg --version > gpg (GnuPG) 2.1.1-beta40 > libgcrypt 1.7.0-beta122 Are you using libgpg-error 1.15 ? That one has a bug commit c307e1f801cd9a25c4a5b9a90073362219d52ee6 Author: Werner Koch Date: Fri Sep 12 12:03:17 2014 +0200 Fix es_fclose for streams opened with "samethread". * src/estream.c (destroy_stream_lock): New. (es_create, do_close): Use new wrapper function. I should better bump the required version if that is the case. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 24 16:11:11 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 24 Nov 2014 16:11:11 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <87egssej82.fsf@vigenere.g10code.de> References: <87sih9gg5f.fsf@vigenere.g10code.de> <547300A1.7050301@sumptuouscapital.com> <87tx1oeplu.fsf@vigenere.g10code.de> <54733AAD.2020208@sumptuouscapital.com> <87egssej82.fsf@vigenere.g10code.de> Message-ID: <54734A8F.6000603@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/2014 04:01 PM, Werner Koch wrote: > On Mon, 24 Nov 2014 15:03, > kristian.fiskerstrand at sumptuouscapital.com said: > >> I reproduced this on a VM running $ gpg --version gpg (GnuPG) >> 2.1.1-beta40 libgcrypt 1.7.0-beta122 > > Are you using libgpg-error 1.15 ? That one has a bug Affirmative. Upgrading to latest git version of libgpg-error fixes the issue. We went for 1.15 as minimum requirement due to the following config check in gnupg 2.1: checking for GPG Error - version >= 1.15... yes (1.18-beta7) ... I'll make sure to push out an updated version to other gentoo users as well. Thanks! - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nunc aut numquam Now or never -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUc0qKAAoJEPw7F94F4TagaLAQALf+gtAKNXXEtnxm+6sncra+ A7z71ArZK84EdC4mX0OGnmjzaMX+P1PA7CRdadM6YEi5mmaa7ktsbsQymCqoGeaK AApDviH7eYB2hBXGUdEswKH6lAydVE/zsIU56zPJeouBfJy3Gfh8LCdXRuaDYMfe BktecW/oYeE9/6A3I+Wzt+zby7t6pgWvBm1HB2PsFRaAJVCMaG81wAXk6DHzm4o5 gxWKvALtNrOvpIKtxpZjL532nLn8JQCIYBKpI5Dn6mNhSa1Rq5p8VVDBHbSDAIVQ BOkzjDH3d7Yl+DZfRY82dAbenmHWOWHncqENOH6A+qR8LOiPPZYO+XL16sfz/TUo Pxkw5cx7QJtbH5PXArC7ouJRG6igGmZtD1Xf+gRrCxTugF+1FK4XJ+yXMLODzlww JsICDYz3cKddwHuf7pIczCtr1SKn/J8YibaFcdJGfrdSLFd+1cYzunbEKOdnmG86 Vk3hj6TjMmdkRtQlDqlqMNx1lu5drCcm/K6npYkeb54jurFFNiUYQDe2MzvFU8qE eWyC2+7K3ZATtdV19QNIqofxk1evWp0KVZPwHlertqA1eO6jIlCkmQ/WMeRH+41F Zn8Us5e4xRt9gEU6plMe8x+2dCw4i17shNIiO2m4nxAKcMWJ4+XZhUMis9VBTidS KH8Q8qif5nkts498Qe3w =FEaZ -----END PGP SIGNATURE----- From jerry at seibercom.net Mon Nov 24 15:03:51 2014 From: jerry at seibercom.net (Jerry) Date: Mon, 24 Nov 2014 09:03:51 -0500 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <87ppcceo8f.fsf@vigenere.g10code.de> References: <201411241001.38899.bernhard@intevation.de> <20141124092453-16648-55173-mailpile@slinky> <87ppcceo8f.fsf@vigenere.g10code.de> Message-ID: <20141124090351.5e0ec147@scorpio> On Mon, 24 Nov 2014 14:12:48 +0100, Werner Koch stated: > To be fair, that changed with Outlook 2010. We merely had not the > resources to change GpgOL to make use of the new Outlook structure. Interesting; has there been any movement on that front? I use Outlook 2013 at my office and that would be a handy feature to have. -- Jerry From ml at kairaven.de Mon Nov 24 16:29:33 2014 From: ml at kairaven.de (K. Raven) Date: Mon, 24 Nov 2014 16:29:33 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <54733AAD.2020208@sumptuouscapital.com> References: <87sih9gg5f.fsf@vigenere.g10code.de> <547300A1.7050301@sumptuouscapital.com> <87tx1oeplu.fsf@vigenere.g10code.de> <54733AAD.2020208@sumptuouscapital.com> Message-ID: <54734EDD.8030103@kairaven.de> Hi Kristian, > I reproduced this on a VM running $ gpg --version > gpg (GnuPG) 2.1.1-beta40 > libgcrypt 1.7.0-beta122 I have tried it with gpg --version gpg (GnuPG) 2.1.1-beta35 libgcrypt 1.6.2 and had no problems: gpg: sende Schl?ssel 0x5A1796454623BA84 auf den hkps-Server hkps.pool.sks-keyservers.net dirmngr[18085.0] DBG: chan_0 -> # Home: /home/user/.gnupg dirmngr[18085.0] DBG: chan_0 -> # Config: /home/user/.gnupg/dirmngr.conf dirmngr[18085.0] DBG: chan_0 -> OK Dirmngr 2.1.1-beta35 at your service dirmngr[18085.0] connection from process 27379 (1000:1000) dirmngr[18085.1] Handhabungsroutine f?r fd 1 gestartet dirmngr[18085.1] DBG: chan_1 -> # Home: /home/user/.gnupg dirmngr[18085.1] DBG: chan_1 -> # Config: /home/user/.gnupg/dirmngr.conf dirmngr[18085.1] DBG: chan_1 -> OK Dirmngr 2.1.1-beta35 at your service dirmngr[18085.1] connection from process 27379 (1000:1000) dirmngr[18085.1] DBG: chan_1 <- KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net dirmngr[18085.1] DBG: chan_1 -> OK dirmngr[18085.1] DBG: chan_1 <- KS_PUT dirmngr[18085.1] DBG: chan_1 -> INQUIRE KEYBLOCK dirmngr[18085.1] DBG: chan_1 <- [ 44 20 99 04 ae 04 49 51 0e 82 11 0c 00 95 6d aa ...(982 byte(s) skipped) ] (...) dirmngr[18085.1] DBG: chan_1 <- [ 44 20 2f 6f e7 d2 86 c8 53 cb 7d ed d4 75 7f 32 ...(709 byte(s) skipped) ] dirmngr[18085.1] DBG: chan_1 <- END dirmngr[18085.1] DBG: chan_1 -> INQUIRE KEYBLOCK_INFO dirmngr[18085.1] DBG: chan_1 <- D pub:5A1796454623BA84 (...) dirmngr[18085.1] DBG: chan_1 <- END dirmngr[18085.1] getnameinfo returned for 'hkps.pool.sks-keyservers.net': 'hkps.pool.sks-keyservers.net' [already known] dirmngr[18085.1] DBG: chan_1 -> S PROGRESS tick ? 0 0 dirmngr[18085.1] DBG: chan_1 -> OK dirmngr[18085.0] DBG: chan_0 <- [eof] dirmngr[18085.0] Handhabungsroutine f?r den fd 0 beendet dirmngr[18085.1] DBG: chan_1 <- BYE dirmngr[18085.1] DBG: chan_1 -> OK closing connection dirmngr[18085.1] Handhabungsroutine f?r den fd 1 beendet dirmngr[18085.0] starting housekeeping dirmngr[18085.0] ready with housekeeping -- Ciao Kai http://kairaven.de/ From josef at netpage.dk Mon Nov 24 16:22:47 2014 From: josef at netpage.dk (Josef Schneider) Date: Mon, 24 Nov 2014 16:22:47 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <87sih9gg5f.fsf@vigenere.g10code.de> References: <87sih9gg5f.fsf@vigenere.g10code.de> Message-ID: <54734D47.2080804@netpage.dk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I cannot get it to work with my OpenPGP card. The card works fine with GPG 2.0 If I try anything needing a secret key, it just outputs "No secret key" D:\>gpg --detach-sign barstick.rar gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: signing failed: No secret key gpg: signing failed: No secret key The card status looks correct: D:\>gpg --card-status gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Application ID ...: D2760001240102000005000010650000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 00001065 Name of cardholder: Schneider Josef Language prefs ...: de Sex ..............: male URL of public key : https://netpage.dk/gpg.asc Login data .......: - Signature PIN ....: forced Key attributes ...: 4096R 4096R 4096R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 893 Signature key ....: CA77 342B 856C 9D5B B0B6 C23C 3140 E873 9BE4 5ED0 c reated ....: 2012-12-10 00:01:57 Encryption key....: DE61 0EF1 5124 2A64 400B 9968 4CBB 978B B641 DD11 created ....: 2012-12-10 00:01:57 Authentication key: 3E9E 5480 F676 B9D6 6632 49A2 E1D8 2ECC CA02 F8EA created ....: 2012-12-10 00:03:06 General key info..: pub rsa4096/9BE45ED0 2012-12-10 Josef Schneider sec# rsa4096/9BE45ED0 created: 2012-12-10 expires: 2017-04-13 ssb# rsa4096/B641DD11 created: 2012-12-10 expires: never ssb rsa4096/CA02F8EA created: 2012-12-10 expires: never I also tried deleting the key and adding it again with gpg -- card-edit, fetch The only thing that even asks for a pin is gpg --card-edit, verify But it seems like this also doesn't work right. It asks me for my PIN and then shows the same info as --card- status But it shows the same info, no matter what PIN I enter and the PIN retry counter is not decremented on a wrong PIN If I enter a wrong PIN, another verify asks for the PIN again. With a right PIN, it doesn't ask! I am confused. Best regards, Josef -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 - GPGshell v3.78 iQIcBAEBCgAGBQJUc00dAAoJEDFA6HOb5F7Q1d0P/33wmc8fTAZNTpZFFMEWdC5n Heqb/hzAFNdPPMj4qNFVEK5OEuGstgvoQ+q7aztw1L34su3Mz34zbK/a0Ennayqf HPyQNJ6yM0l68zO/hs5OWnXZ5lz9XXhiJb1wMxwse/u6BNSO1uoNgva5RhzpJY6E rdPRVmLcUhcMSI837yw0sHGs8JaLeHQ10j9K4B85aB7f82DNVHE0RCgq1zEH+9V4 kBT/yV5uWuEys4tw8T5Y9ZpW4rBRoFWg0nCmXgCazbrlpN9+ZEn4LPlZEJPlqPPs m0lU88oQqsWJCP3L5kmxZbYVdmfxLO5PjluFu+J0MPQryyCQCffybBB/0zNiE9ji WkZQVyhfYyAfnlhrmvJ4eZMcRz9VOcij91Cz6fhrcOfcjBzRdT9/GROg8HtzVxfy 2W6yKnJCq0l0VG1rXhwpbopzvmBlu8ZL2HwToD8vKTgirfVpwbxwBq4PU8i1kwev bzS9dFTmuglU/uRod7VMQCP8MCPPnLzugXFYXjsBDOSWzzIY5ri4GI+6LOs82f00 58+VROq0LmH64WJwV2OHWk77w1KoLWoEOEFGEWTGEXkwLF3yKcss6e8qZ3Z6bgs1 SlwBPJZsZzTqqoaLPQGOWy+qDlC204L/pkldbRsByP17MKkvgbiyAkozlrGaDHcR XoXdcviQYFj5DtluTEUz =lMLh -----END PGP SIGNATURE----- > Werner Koch > Montag, 24. November 2014 09:24 > Hi, > > mainly to test the fixes to the Windows installer, I did a quick beta > last Friday. However, while testing it I found that in GPA the export > of keys to the keyserver does still not work. Instead of delaying a > test release even more I have published that installer anyway. > > Thus most things should be fixed and the Windows version should be > usable from the command line, via GPA, and in the explorer. Of course > there are still open bugs and I continue to work on them. The installer > has a new graphics on the welcome page but it is a pretty stupid one. > If someone has the talents creating a nice one, we could include that in > the next release [1]. > > To not bother the mirros with this test release the files are in my > scratch directory (and will eventually be removed): > > 1. The installer: > > ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.exe > > ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.exe.sig > > 2. The complete but large sources including all GTK+ stuff to comply > with the GPL: > > ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.tar.xz > > ftp://ftp.gnupg.org/people/werner/scratch/gnupg-w32-2.1.1-beta35_20141121.tar.xz.sig > > 3. A proper GnuPG source tarball: > > ftp://ftp.gnupg.org/people/werner/scratch/gnupg-2.1.1-beta35.tar.bz2 > > ftp://ftp.gnupg.org/people/werner/scratch/gnupg-2.1.1-beta35.tar.bz2.sig > > > Checksums: > > ec1443da83dff4648cc73deb34113f8a8f261791 > gnupg-w32-2.1.1-beta35_20141121.exe > 9bca63c32bb06abe9b501d1464a65ccdb82a71b1 > gnupg-w32-2.1.1-beta35_20141121.tar.xz > f57dc5c21e118f7d4289137e2a6a08ab6e877e91 gnupg-2.1.1-beta35.tar.bz2 > > > Bug reports please to the gnupg-users. > > > GnuPG changes in 2.1.1-beta35 > ----------------------------- > > * gpg: Detect faulty use of --verify on detached signatures. > > * gpg: New import option "keep-ownertrust". > > * gpg: Fixed regression in --refresh-keys. > > * gpg: Fixed best matching hash algo detection for ECDSA and EdDSA. > > * gpg: Improved perceived speed of secret key listisngs. > > * gpg: Print number of skipped PGP-2 keys on import. > > * gpgconf --kill does not anymore start a service only to kill it. > > * Fixed keyserver access for Windows. > > * Fixed build problems on Mac OS X > > * The Windows installer does now install development files > > * More translations (but most of them are not complete). > > > GPA in version 0.9.6 (2014-11-21) > ---------------------------------- > > * Support keyserver operations for GnuPG 2.1. > [But send keys does not yet work] > > * Implement the IMPORT_FILES server command. > > * New "Refresh Key" action in the key manager's context menu. > > > Note that in GPA's settings dialo there is no more list of keyservers. > This is now configured in the Backend Preferences under the GPG tab > because it uses the GPG directly. > > > > Salam-Shalom, > > Werner > > > > > [1] This should be a 164 x 314 x 8 colors, no transparency and white > background. I can convert it to the required Windows format. The GnuPG > logo master and variants of it can be found at: > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From patrick at enigmail.net Mon Nov 24 17:39:46 2014 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 24 Nov 2014 17:39:46 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> Message-ID: <54735F52.2030205@enigmail.net> On 24.11.14 09:24, Werner Koch wrote: [...] > > GnuPG changes in 2.1.1-beta35 > ----------------------------- > [...] > * Fixed build problems on Mac OS X All fixed indeed! I created the first GnuPG build that did not require a single patch on OS X :-) -Patrick From MichaelQuigley at TheWay.Org Mon Nov 24 17:57:37 2014 From: MichaelQuigley at TheWay.Org (MichaelQuigley at TheWay.Org) Date: Mon, 24 Nov 2014 11:57:37 -0500 Subject: Encryption on Mailing lists sensless? In-Reply-To: <145713323.20141122211638@my_localhost> References: <145713323.20141122211638@my_localhost> Message-ID: MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote on 11/22/2014 04:16:38 PM: > From: MFPA <2014-667rhzu3dc-lists-groups at riseup.net> > To: "MichaelQuigley at TheWay.Org on GnuPG-Users" > Cc: "MichaelQuigley at TheWay.Org" > Date: 11/22/2014 04:16 PM > Subject: Re: Encryption on Mailing lists sensless? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Wednesday 19 November 2014 at 7:50:32 PM, in > , > MichaelQuigley at TheWay.Org wrote: > > > > > > Which of course would not be possible if the public > > mailing list was all encrypted. > > Unless the search engine subscribed to the encrypted list and produced > search results in the clear. > > - -- > Best regards And I'm not sure what we would be doing there except burning extra CPU cycles encrypting everything that's now publically available because the search engine has it all decrypted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Mon Nov 24 19:26:38 2014 From: mirimir at riseup.net (Mirimir) Date: Mon, 24 Nov 2014 11:26:38 -0700 Subject: Encryption on Mailing lists sensless? In-Reply-To: References: <145713323.20141122211638@my_localhost> Message-ID: <5473785E.2040507@riseup.net> On 11/24/2014 09:57 AM, MichaelQuigley at TheWay.Org wrote: > MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote on 11/22/2014 > 04:16:38 PM: > >> From: MFPA <2014-667rhzu3dc-lists-groups at riseup.net> >> To: "MichaelQuigley at TheWay.Org on GnuPG-Users" >> Cc: "MichaelQuigley at TheWay.Org" >> Date: 11/22/2014 04:16 PM >> Subject: Re: Encryption on Mailing lists sensless? >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi >> >> >> On Wednesday 19 November 2014 at 7:50:32 PM, in >> > , >> MichaelQuigley at TheWay.Org wrote: >> >> >> >> >>> Which of course would not be possible if the public >>> mailing list was all encrypted. >> >> Unless the search engine subscribed to the encrypted list and produced >> search results in the clear. >> >> - -- >> Best regards > > And I'm not sure what we would be doing there except burning extra CPU > cycles encrypting everything that's now publically available because the > search engine has it all decrypted. Well, membership would presumably be by invitation only. With end-to-end encryption, recipients could be confident about the integrity of messages. And messages could be uniquely watermarked for each recipient, so that leakers could be identified, and dropped from the list. From greg at turnstep.com Mon Nov 24 18:18:30 2014 From: greg at turnstep.com (Greg Sabino Mullane) Date: Mon, 24 Nov 2014 17:18:30 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124092453-16648-55173-mailpile@slinky> Message-ID: <949f0faaaf1fa7b0419c827cc393783e@biglumber.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Bjarni Runar Einarsson wrote: > Of course, today encryption is so rare that the only folks encountering > this problem are nontechnical people, journalists and activists and the > like, and they just give up and us something else to communicate and we > don't hear from them again. This is not true. I am an active user of PGP for encryption and signing, and hear from technical *and* non-technical people all the time about issues with reading or verifying or decrypting my emails. I use both plaintext and MIME as the situation dictates, but there are major problems with both, so +1 on trying to think outside the box. > 1) Are these problems as common as my experiences imply, or am I just > really unlucky? Bad mail client support for PGP is still very common. This only compounds the mental hurdles users need to understand things. > 2) Is there any interest in trying to improve the standards? The cynic in me will point out that we already have problems getting email clients to follow the existing standards, but improvement is always welcome. :) - -- Greg Sabino Mullane greg at turnstep.com PGP Key: 0x14964AC8 201411241217 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlRzaDAACgkQvJuQZxSWSsgzkQCdFgGixfR/eid3e8wfLTj7FWTQ ER8AnjSdnKy5bvWYElcGo+u2frnnMFv8 =iuIl -----END PGP SIGNATURE----- From wk at gnupg.org Mon Nov 24 20:13:18 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 20:13:18 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <54735F52.2030205@enigmail.net> (Patrick Brunschwig's message of "Mon, 24 Nov 2014 17:39:46 +0100") References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> <54735F52.2030205@enigmail.net> Message-ID: <87oarwcsz5.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 17:39, patrick at enigmail.net said: > All fixed indeed! I created the first GnuPG build that did not require a > single patch on OS X :-) Yeah! Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 24 20:14:56 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Nov 2014 20:14:56 +0100 Subject: Beta for 2.1.1 available In-Reply-To: <54734D47.2080804@netpage.dk> (Josef Schneider's message of "Mon, 24 Nov 2014 16:22:47 +0100") References: <87sih9gg5f.fsf@vigenere.g10code.de> <54734D47.2080804@netpage.dk> Message-ID: <87k32kcswf.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 16:22, josef at netpage.dk said: > I cannot get it to work with my OpenPGP card. > The card works fine with GPG 2.0 > If I try anything needing a secret key, it just outputs "No > secret key" This is known. As a worrkaround use gpg-connect-agent learn /bye Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hugo.hinterberger at gmx.net Mon Nov 24 15:37:57 2014 From: hugo.hinterberger at gmx.net (Hugo Hinterberger) Date: Mon, 24 Nov 2014 15:37:57 +0100 Subject: Beta for 2.1.1 available References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> Message-ID: Hi, On Mon, 24 Nov 2014 09:24:28 +0100, Werner Koch wrote: > GnuPG changes in 2.1.1-beta35 I noticed that for malformed PGP messages there is no notification of the user in GPA. When verifying a malformed PGP message an empty verification result windows is shown (see attached image). > * Fixed keyserver access for Windows. > GPA in version 0.9.6 (2014-11-21) > ---------------------------------- > > * Support keyserver operations for GnuPG 2.1. > [But send keys does not yet work] I am still not able to load (receive) keys from key servers. On the command line I get the error "keyserver receive failed: No keyserver available". in GPA I get the warning message "No keys were found.". I verified, that the key is available on the key servers. I attached my (redacted) gpg.conf Regards, Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: GPA - no result.png Type: image/png Size: 73481 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.conf Type: application/octet-stream Size: 1115 bytes Desc: not available URL: From aixtools at gmail.com Mon Nov 24 19:51:18 2014 From: aixtools at gmail.com (Michael Felt) Date: Mon, 24 Nov 2014 19:51:18 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: <87d28cg6k1.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87d28cg6k1.fsf@vigenere.g10code.de> Message-ID: I think it has to do with the interpretation of the return value - AIX is always zero on success, and something different when not a success. What that is is returned in errno. See: for i in 2 4 5 do cc -o conftest$i conftest$i.c -liconv echo CONFTEST$i ./conftest$i | od -bc echo done CONFTEST2 ./conftest2:iconv_t cd_utf8_to_88591 = iconv_open ("UTF-8", "ISO8859-1"); result: -1 errno: 7 0000000 072 062 060 060 060 060 071 071 070 012 303 242 072 062 060 060 : 2 0 0 0 0 9 9 8 \n ? ? : 2 0 0 0000020 060 060 071 071 070 012 076 076 342 202 254 074 074 012 133 133 0 0 9 9 8 \n > > ? 202 ? < < \n [ [ 0000040 303 242 135 135 012 060 040 062 012 ? ? ] ] \n 0 2 \n 0000051 CONFTEST4 ./conftest4:iconv_t cd_utf8_to_88591 = iconv_open ("UTF-8", "ISO8859-1"); result: -1 errno: 7 0000000 072 062 060 060 060 060 071 071 070 012 101 102 072 062 060 060 : 2 0 0 0 0 9 9 8 \n A B : 2 0 0 0000020 060 060 071 071 070 012 076 076 101 102 103 104 074 074 012 133 0 0 9 9 8 \n > > A B C D < < \n [ 0000040 133 101 102 135 135 012 060 040 062 012 [ A B ] ] \n 0 2 \n 0000052 CONFTEST5 ./conftest5:iconv_t cd_utf8_to_88591 = iconv_open ("ISO8859-1", "UTF-8"); result: 0 errno: 0 return 1 0000000 072 062 060 060 060 060 071 071 070 012 032 072 062 060 060 060 : 2 0 0 0 0 9 9 8 \n 032 : 2 0 0 0 0000020 060 071 071 070 012 076 076 342 202 254 074 074 012 133 133 032 0 9 9 8 \n > > ? 202 ? < < \n [ [ 032 0000040 135 135 012 071 040 061 012 ] ] \n 9 1 \n 0000047 Also attached, the config.log as requested. On Mon, Nov 24, 2014 at 12:51 PM, Werner Koch wrote: > On Sat, 22 Nov 2014 16:30, aixtools at gmail.com said: > > > However, configure is reporting - in config.log that AIX does not have > > libiconv - which it does. So, my question is: to which gnu tool should I > > Well, the code does not detect it or it is not usable. The latter > should be reported. > > The detection code is source copied in GnuPG and used to create the > configure script. Some parts have not been updated for a long time and > thus it might help to update them. Can you send me the complete > config.log by private mail? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 376789 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: conftest2.c Type: text/x-csrc Size: 2608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: conftest4.c Type: text/x-csrc Size: 2608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: conftest5.c Type: text/x-csrc Size: 2609 bytes Desc: not available URL: From simon at bleah.co.uk Mon Nov 24 20:45:33 2014 From: simon at bleah.co.uk (Simon Ward) Date: Mon, 24 Nov 2014 19:45:33 +0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124124407-16648-6736-mailpile@slinky> References: <871tosg4vi.fsf@vigenere.g10code.de> <20141124124407-16648-6736-mailpile@slinky> Message-ID: <9091c166-91b9-433a-8496-c53c6bf5d089@email.android.com> On 24 November 2014 12:44:31 GMT+00:00, Bjarni Runar Einarsson wrote: >> Wrap in a message/rfc822 part. > >If PGP/MIME had proposed this from the start, then I wouldn't be able >to >make cheap shots about Subject lines and indeed, living with the other >problems would be far more palatable. > >But PGP/MIME missed that boat, and the user experience of a >message/rfc822 part inside a multipart encrypted wrapper is really not >acceptable in today's clients. I currently use Thunderbird and Mutt, both of which can open "emails within emails" as MIME parts, but I'm fairly certain Outlook from Office 2002 coped with them too. Granted, it's still an extra step with those MUAs, but all they need to do is handle MIME, which is a container just as much as Zip is. Why introduce Zip as yet another container, and yet another thing for diverse MUAs to handle instead of using one that many MTAs already support? Simon -- Sent from Kaiten Mail. Please excuse my brevity. From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 24 21:40:22 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 24 Nov 2014 21:40:22 +0100 Subject: Beta for 2.1.1 available In-Reply-To: References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> Message-ID: <547397B6.3040308@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/2014 03:37 PM, Hugo Hinterberger wrote: > Hi, Hi Hugo, ... > I am still not able to load (receive) keys from key servers. On > the command line I get the error "keyserver receive failed: No > keyserver available". in GPA I get the warning message "No keys > were found.". I verified, that the key is available on the key > servers. I attached my (redacted) gpg.conf > For 2.1 you need the following in dirmngr.conf: hkp-cacert /path/to/sks-keyservers.netCA.pem instead of keyserver-options ca-cert-file="C:/Users//AppData/Roaming/gnupg/sks-keyservers.netCA.crt" - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Aut dosce, aut disce, aut discede Either teach, or study, or leave -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUc5e0AAoJEPw7F94F4TagoGIQAJBMG/F6lmdZirgnzBTAEM/M GabDiHJWdXq6Sb5C+oSOprPuSOqINpyPPBM86pdL/BXMINWqTmAo40AZ/UH60h71 xQo+6/Sv+guzeTX4WZjsDmuimL1AQZxBbGM0hZQNsaovrPruu8WfVos7IiS56iN9 DLI/NMNFdj2nGYbwsTQ+zrw7QLLOk3ivbIZA5xDgo5gHH77inZxMT18BKpQlCvwz 0h+HvJNSm7Nd4b7Uu21XCc72tXwqjTGeegFpzDldUSVT4txG+6afU9qrVd23tTm8 JnftUm5RJ+YN6CvfrL8eBhUbTLgKFxvXzzaBZbaIXNXZifcVZ7H+2UBTj2fRdNHT MRKYvmhUTReQyDbL7wXkamF2QhRBXW5jy3pZwZqoo2NHId4LSRhvuix6Stzd4nA2 o4wPHVUS1OIRgq+mxh2qWnU5MeLt92uk3poeIjwGJE1k8W+r4zEJKmnx7F8upO6V j9zDMvqCvpm3guLbE2mNS7Xuc51v8mHC2/KJ4ZuPvJcBjlkwp6Mp2+NauPOPaFmK yZvxPYeKymddufAA4ls5m2aj0aRMhOMWNxMIsYlDoZH3iQvQeSIZ++RhWblIY2mK XmM5SUybAN36o0FsvMW+K4c7EqQGTbkX+PRnWcLKbX+MuRoCQf+KRf/GNjen//Uj yxwtw4ZpbwNEJlJCmvGo =Ptq3 -----END PGP SIGNATURE----- From simon+gnupg at bleah.co.uk Mon Nov 24 21:10:00 2014 From: simon+gnupg at bleah.co.uk (Simon Ward) Date: Mon, 24 Nov 2014 20:10:00 +0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <9091c166-91b9-433a-8496-c53c6bf5d089@email.android.com> References: <871tosg4vi.fsf@vigenere.g10code.de> <20141124124407-16648-6736-mailpile@slinky> <9091c166-91b9-433a-8496-c53c6bf5d089@email.android.com> Message-ID: <822b482d-8b63-44f1-8bf6-7a8fdfb8582e@email.android.com> On 24 November 2014 19:45:33 GMT+00:00, I wrote: >On 24 November 2014 12:44:31 GMT+00:00, Bjarni Runar Einarsson > wrote: >>> Wrap in a message/rfc822 part. >> >>If PGP/MIME had proposed this from the start, then I wouldn't be able >>to >>make cheap shots about Subject lines and indeed, living with the other >>problems would be far more palatable. >> >>But PGP/MIME missed that boat, and the user experience of a >>message/rfc822 part inside a multipart encrypted wrapper is really not >>acceptable in today's clients. > >I currently use Thunderbird and Mutt, both of which can open "emails >within emails" as MIME parts, but I'm fairly certain Outlook from >Office 2002 coped with them too. Granted, it's still an extra step with >those MUAs, but all they need to do is handle MIME, which is a >container just as much as Zip is. Why introduce Zip as yet another >container, and yet another thing for diverse MUAs to handle instead of >using one that many MTAs already support? I do find it a little bit ironic that I am also using Kaiten Mail (a derivative of K-9 Mail) for Android to send these very emails, but have user interface troubles even just to send with a different alias. Never mind that I have stopped generally signing emails because I kept my primary key offline and APG did not handle the sub-keys. Oh well. Simon -- Sent from Kaiten Mail. Please excuse my brevity. From bre at pagekite.net Mon Nov 24 21:48:39 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Mon, 24 Nov 2014 20:48:39 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <9091c166-91b9-433a-8496-c53c6bf5d089@email.android.com> References: <9091c166-91b9-433a-8496-c53c6bf5d089@email.android.com> Message-ID: <20141124204810-16648-55252-mailpile@slinky> Hi Simon, thanks for the comments. Simon Ward wrote: > > I currently use Thunderbird and Mutt, both of which can open "emails > within emails" as MIME parts, but I'm fairly certain Outlook from Office > 2002 coped with them too. Granted, it's still an extra step with those > MUAs, but all they need to do is handle MIME, which is a container just > as much as Zip is. Why introduce Zip as yet another container, and yet > another thing for diverse MUAs to handle instead of using one that many > MTAs already support? The reasons I don't want to put the text part in a container at all, but am willing to consider doing so for attachments are as follows: 1. Mail clients have user interfaces that are at least somewhat optimized for conversations, like the one we are having now. Moving the text part into a container (rfc2822 or otherwise) breaks that flow for everyone. 2. For attachments, that flow is less entrenched. Granted, many MUAs will open an application when you click on an attachment, but others will save to disk, still others will offer a choice. Adding an extra step here (interacting with the container) is off the critical path of how the mail client is most often used. It is still an extra step though, and extra code to write in the MUA, which is one of the reasons I not sure about the merits of using a container at all. Note that if the container is a ZIP file, that will work without extra tools on all modern OSes (if I recall, I need to double-check a fresh Windows install), but that is certainly not true for RFC2822 or tar (which was suggested on the Hacker News thread about my blog post). Using RFC2822 will work if you have a nice desktop mail client, but if you do, then you also have (the option of) PGP/MIME support and are not the user I am trying to help with this proposal. As stated in my post - my proposal makes life marginally worse for people with PGP/MIME compliant MUAs (working with attachments becomes less fun), but better for everyone else. I haven't come up with a way around that yet, short of shipping 2 of everything in each message. :-) Cheers! - Bjarni -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From bernhard at intevation.de Tue Nov 25 09:42:07 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Nov 2014 09:42:07 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124092453-16648-55173-mailpile@slinky> References: <201411241001.38899.bernhard@intevation.de> <20141124092453-16648-55173-mailpile@slinky> Message-ID: <201411250942.17695.bernhard@intevation.de> Hi Bjarni, On Monday 24 November 2014 at 10:25:43, Bjarni Runar Einarsson wrote: > Bernhard Reiter wrote: > And thank you for the friendly reply. :-) you are welcome! I know that some people sound a little but grumpy, but this mostly is the case, because they feel like they are reiterating well known arguments. This is partly true. Still I believe that we all feel some pressure to make the situation better for users. So we may need to rethink the solutions radically again, to see if we come to the same answer. > > I am on the PGP/MIME side of things, I recommend it as default for > > sending out emails. See also http://wiki.gnupg.org/SignatureHandling . > > > > a) for encrypted emails, there is no drawback. Every email client just > > have to be able to deal with message/rfc822 mime-parts anyway. > > I actually disagree, the drawbacks are significant if you broaden the > scope to include users of mail clients that do not have native support - > which once you step out of the Free Software bubble, is most mail > clients. You are saying that "most mail" clients cannot handle PGP/MIME encrypted email. And you say that is especially true for web based email clients. My argument starts at: almost all MUAs (mail user clients) can deal with MIME. So they must have a working MIME parser. For them to implement PGP/MIME for decryption is very easy: Just decrypt the contents and put it through the parser they already have. If someone aims for implementing this, it can be done easily. > As discussed in my post, if you have a PGP key but are unable to use a > PGP/MIME aware mail client for whatever reason (work supplied laptop, no > Internet outside of Internet caf?s etc.), then you will not easily be > able to receive and decrypt PGP/MIME attachments, In this case of course they might also lack the standard tools to unzip the archive in your first ad-hoc strategy. So it will be better to fall back on an attachment (that includes an archive file) that people can decrypt. Oh, what about the idea to just ship a MIME parser with GnuPG. >;) If more people implement the good standard PGP/MIME, more clients will implement it as well. So I see that sending PGP/MIME as default is good, with an option that the user can fall back to a zipped and encrypted (gpg-zip/gpg-tar compatible format) attachment, > It is tempting to blame the Python libraries, but the fact > is that they do generate valid MIME - after swearing at Python for > months, it dawned on me that it's probably the PGP/MIME standard that is > just being too picky. The email standard library assumed that whitespace and header lines are insignificant (last time I've looked, I think I even filed an issue with mailman and with python, but it was a long while ago). So they completely disassemble them to put the together again when they are needed. In this process they strip whitespaces, headerlines and reformat linebreaks. So there is a designed loss of information in the library. To me that is a design issue of the library. And I believe most other MIME libraries will not share it. From the security point of view I think it is good that PGP/MIME enforces that mime(sub)parts will not be modified, because if you allow changes there, which are to be assumed identical, you may introduce an attack surface because some clients may display the contents slight differently. A clever attacker may exploit this to play tricks on the user. > This is part of what I meant by tightly coupled in a previous e-mail - > unless MIME libraries and interfaces are explicitly written with > PGP/MIME in mind, and carefully tested, they easily end up being > incompatible. There is one criteria added to the design of MIME libraries: If I save a mime object -- let us say an message/rfc822 -- I can get it out the same way I have put it in. I'd say that this would be good design anyway. Again, the problem is only really there for signatures verification or email forwarding or so. For encryption, you are writing your own mime-parts so it is easy to not create strange headers or double whitespaces in them. For decryption you just decrypt the blob and then have a regular MIME structure. > MIME is a forgiving standard, PGP/MIME is emphatically > not. This causes headaches for people trying to implement PGP/MIME and > any source of friction like this reduces tool support and uptake. There are some rules about whitespace to not have it getting in the way, but in general conceptually I see no other way, if you want to make sure that an email has not been tampered with. > All the other issues aside, I don't think anyone will > seriously argue that an e-mail encryption standard which transmits the > subject line in the clear is a "good standard". If you want some indication about what the communication is about before opening it, the indication has to be on the "envelope" and thus cannot be encrypted. Once opened, there can be a different contents. I can think of coming up with something where there is a second message/rfc822 within the message and the subject: line in there should be displayed instead of the envelope subject by email clients that have already done the complete decryption (though then you have the interface problem where to display the envelope subject). In total I would say that having an envelope subject is good anyway and that most email clients would continue to display it, because it could contain important information still. > So really, I guess I'm asking this community for feedback on two things: > > 1) Are these problems as common as my experiences imply, or am I just > really unlucky? I'd say you are slightly unlucky with pythons "email" library. (It is really hard to say from the little I know.) > 2) Is there any interest in trying to improve the standards? There is always (some) interest, but it is hard work. Some of your assumptions do not seem to be shared in full by others. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From gnupgpack at on.yourweb.de Tue Nov 25 09:31:30 2014 From: gnupgpack at on.yourweb.de (gnupgpack at on.yourweb.de) Date: Tue, 25 Nov 2014 09:31:30 +0100 Subject: gpg.conf: settings for security and compatibility Message-ID: <537031.54744C76.0004@gate> Hello to all, my newbie post... I am struggling with gpg.conf for GnuPG-Pack-14.11.x (gpg 1.4.18). Dealing with encryption should be secure, cross-mailer interoperability and compatibility should be maximized between PGP/GnuPG/GPG/OpenPG and different os (Win/Mac/Linux). There are some known hash size problems with Debian (no SHA 512), so SHA256 will be used. Newer SmartCards accept keysize <= 3072 bit. Key is divided in: masterkey C (RSA4096) subkey A (RSA3072) subkey E (RSA3072) subkey S (DSA3072, smaller sig!) Suggestion for gpg.conf (pls optimize, I am a newbie...): fixed-list-mode # keyserver hkp://eu.pool.sks-keyservers.net # default-keyserver-url hkp://eu.pool.sks-keyservers.net expert enable-large-rsa s2k-count 1000000 s2k-digest-algo SHA256 s2k-cipher-algo AES256 cert-digest-algo SHA256 digest-algo SHA256 personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 3DES personal-digest-preferences SHA256 SHA384 SHA512 SHA224 personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed default-preference-list SHA256 SHA384 SHA512 SHA224 AES256 TWOFISH AES192 AES CAST5 3DES ZLIB BZIP2 ZIP Uncompressed no-emit-version use-agent verify-options show-uid-validity,show-notations,show-policy-urls,show-keyserver-urls list-options show-uid-validity,show-notations,show-policy-urls,show-keyserver-urls,show-s ig-expire Is there a proofed gpg.conf out there? Thanks, best regards, @g. From dkg at fifthhorseman.net Tue Nov 25 10:39:27 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 25 Nov 2014 04:39:27 -0500 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <201411250942.17695.bernhard@intevation.de> References: <201411241001.38899.bernhard@intevation.de> <20141124092453-16648-55173-mailpile@slinky> <201411250942.17695.bernhard@intevation.de> Message-ID: <54744E4F.30506@fifthhorseman.net> On 11/25/2014 03:42 AM, Bernhard Reiter wrote: > On Monday 24 November 2014 at 10:25:43, Bjarni Runar Einarsson wrote: >> It is tempting to blame the Python libraries, but the fact >> is that they do generate valid MIME - after swearing at Python for >> months, it dawned on me that it's probably the PGP/MIME standard that is >> just being too picky. > The email standard library assumed that whitespace and header lines are > insignificant (last time I've looked, I think I even filed an issue with > mailman and with python, but it was a long while ago). So they completely > disassemble them to put the together again when they are needed. In this > process they strip whitespaces, headerlines and reformat linebreaks. > So there is a designed loss of information in the library. > To me that is a design issue of the library. And I believe most other MIME > libraries will not share it. > > From the security point of view I think it is good that PGP/MIME enforces > that mime(sub)parts will not be modified, because if you allow changes there, > which are to be assumed identical, you may introduce an attack surface > because some clients may display the contents slight differently. A clever > attacker may exploit this to play tricks on the user. This is also a violation of RFC 3156, which extends https://tools.ietf.org/html/rfc2015#section-3 Multipart/signed and multipart/encrypted are to be treated by agents as opaque, meaning that the data is not to be altered in any way [1]. Which goes all the way back to RFC 1847 from October 1995 :/ This is supposed to be http://bugs.python.org/issue1670765, which is claimed to be resolved. If it's not resolved, someone needs to let the python devs know about it. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From hugo.hinterberger at gmx.net Tue Nov 25 10:50:24 2014 From: hugo.hinterberger at gmx.net (Hugo Hinterberger) Date: Tue, 25 Nov 2014 10:50:24 +0100 Subject: Beta for 2.1.1 available References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> <547397B6.3040308__6448.01360690526$1416861938$gmane$org@sumptuouscapital.com> Message-ID: Hi Kristian, On Mon, 24 Nov 2014 21:40:22 +0100, Kristian Fiskerstrand wrote: > For 2.1 you need the following in dirmngr.conf: > hkp-cacert /path/to/sks-keyservers.netCA.pem > > instead of > keyserver-options > ca-cert-file="C:/Users//AppData/Roaming/gnupg/sks-keyservers.netCA.crt" OK, so: sks-keyservers.netCA.crt is a PEM encoded (...BEGIN CERTIFICATE...END CERTIFICATE...) certificate and is hardlinked to sks-keyservers.netCA.pem . The files are located in %appdata%/gnupg/ . In dirmngr.conf I have the following line: hkp-cacert "C:/Users//AppData/Roaming/gnupg/sks-keyservers.netCA.pem" In gpg.conf I have also the following line: keyserver-options ca-cert-file="C:/Users/hinterberger.h/AppData/Roaming/gnupg/sks-keyservers.netCA.crt" This means I have both options set => no change: No keyserver available. I commented out the line in gpg.conf => still no change. Pinging the keyserver works. Hmm... I just tried to: > wget --certificate=sks-keyservers.netCA.pem > "https://hkps.pool.sks-keyservers.net/pks/lookup?op=get&search=0x8BCF070743176C6A" and I got: OpenSSL: error:0906D06C:PEM routines:PEM_read_bio:no start line OpenSSL: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib Disabling SSL due to encountered errors. OK, using "--ca-certificate" instead of "--certificate" worked, so the network seems to be OK. gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 0x8BCF070743176C6A gpg --keyserver https://hkps.pool.sks-keyservers.net --recv-key 0x8BCF070743176C6A Both fail. Using hkp, on the other hand, works. Regards, Hugo From kristian.fiskerstrand at sumptuouscapital.com Tue Nov 25 10:57:34 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 25 Nov 2014 10:57:34 +0100 Subject: Beta for 2.1.1 available In-Reply-To: References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> <547397B6.3040308__6448.01360690526$1416861938$gmane$org@sumptuouscapital.com> Message-ID: <5474528E.3070001@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/25/2014 10:50 AM, Hugo Hinterberger wrote: > Hi Kristian, > > On Mon, 24 Nov 2014 21:40:22 +0100, Kristian Fiskerstrand > wrote: > >> For 2.1 you need the following in dirmngr.conf: hkp-cacert >> /path/to/sks-keyservers.netCA.pem >> ... > > Both fail. Using hkp, on the other hand, works. > Try using --debug 1024 and see what the dirmngr output is. One possibility is that it is related to [0] References: [0] http://lists.gnupg.org/pipermail/gnupg-users/2014-November/051471.html - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "The best way to predict the future is to invent it" (Alan Kay) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUdFKNAAoJEPw7F94F4TagUW4P/2t2AxWwMnWc2UK9CrqVGpmS j+2tdkF+E/E3jyFZQCmRx9yWi3QiQ4KsizA0eiNGSyGESJHnb0+HdpZcvKRK3NVF NLXimMQm6RwXUcnsr6jmsU0K3xOp1wODwH25iCmWrOOFbpfTDdIL5RSatdaBpxRi Pq+ZupjYmCzctbB5iXI9/LBNseHJzgVmvVWbGOviEgDjqXjB7s06Q4FFB4HORIXA t4TGwwZBONnNQrrYkktpjcguk7QgO+Yb8KjJespophx/UD7+hKDDc54UwlUte8fT cTPLuX9mz295GcoDkId0xMF7Tl3ojQMLYR3DlE3CCosaAUxSGoVqlxWuDOdwTPfB YI7Kj5eXvHwHuJ08Cjf1ShnU66zsHkhqWPWJZ+LAzGSIDBRgyphTGkbaIvBGHkrA MQo/kbXZq+qpDFwrL4zPFyCTGUyD1Ga5UDnDjoimcVl1X6aMRdOc7RJ60qsaYiMp 3dVhoijZKd/2VqBFJpvEz56gWVWzTpkzU7Mki0abr0JKCxtgspMYxUw9EV0N9cMl 83+4tHrSzNOOKrXfOSI80kDPygbA3Y5hSAU6u4o2DGjL5KYLAnad32B0jz1vwacG pWAtFF2swVWQY/F8XudfEnTSLto2HbKkBt+um7i9exZG3QW7R6LTEuvTDSa8uS/P XyrjR77fpg7CSPcegjUu =ot/3 -----END PGP SIGNATURE----- From hugo.hinterberger at gmx.net Tue Nov 25 12:41:27 2014 From: hugo.hinterberger at gmx.net (Hugo Hinterberger) Date: Tue, 25 Nov 2014 12:41:27 +0100 Subject: Beta for 2.1.1 available References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> <547397B6.3040308__6448.01360690526$1416861938$gmane$org@sumptuouscapital.com> <5474528E.3070001__36704.5255880386$1416910520$gmane$org@sumptuouscapital.com> Message-ID: On Tue, 25 Nov 2014 10:57:34 +0100, Kristian Fiskerstrand wrote: > On 11/25/2014 10:50 AM, Hugo Hinterberger wrote: >> Hi Kristian, >> >> On Mon, 24 Nov 2014 21:40:22 +0100, Kristian Fiskerstrand >> wrote: >> >>> For 2.1 you need the following in dirmngr.conf: hkp-cacert >>> /path/to/sks-keyservers.netCA.pem >>> > > ... > >> >> Both fail. Using hkp, on the other hand, works. >> > > > Try using --debug 1024 and see what the dirmngr output is. One > possibility is that it is related to [0] I ran: dirmngr.exe --debug 1024 --daemon --homedir C:/Users//AppData/Roaming/gnupg and gpg --debug 1024 --keyserver=hkps://hpks.pool.sks-keyservers.net --recv-key 0x8BCF070743176C6A and get the following output: dirmngr: dirmngr[7012]: reading options from 'C:/Users//AppData/Roaming/gnupg/dirmngr.conf' dirmngr[7012]: NOTE: this is a development version! dirmngr.log: 2014-11-25 11:46:24 dirmngr[7012] listening on socket 'C:\Users\\AppData\Roaming\gnupg\S.dirmngr' 2014-11-25 11:46:24 dirmngr[7012] permanently loaded certificates: 0 2014-11-25 11:46:24 dirmngr[7012] runtime cached certificates: 0 2014-11-25 11:46:33 dirmngr[7012] handler for fd 232 started 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000E8 -> # Home: C:/Users//AppData/Roaming/gnupg 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000E8 -> # Config: C:/Users//AppData/Roaming/gnupg/dirmngr.conf 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000E8 -> OK Dirmngr 2.1.1-beta35 at your service 2014-11-25 11:46:33 dirmngr[7012] handler for fd 244 started 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> # Home: C:/Users//AppData/Roaming/gnupg 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> # Config: C:/Users//AppData/Roaming/gnupg/dirmngr.conf 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> OK Dirmngr 2.1.1-beta35 at your service 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 <- KEYSERVER --clear hkps://hpks.pool.sks-keyservers.net 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> OK 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 <- KEYSERVER hkps://hkps.pool.sks-keyservers.net 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> OK 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 <- KS_GET -- 0x8BCF070743176C6A 2014-11-25 11:46:33 dirmngr[7012] command 'KS_GET' failed: No keyserver available 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> ERR 167772346 No keyserver available 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 <- BYE 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000F4 -> OK closing connection 2014-11-25 11:46:33 dirmngr[7012] handler for fd 244 terminated 2014-11-25 11:46:33 dirmngr[7012] DBG: chan_000000E8 <- [eof] 2014-11-25 11:46:33 dirmngr[7012] handler for fd 232 terminated gpg: gpg: reading options from 'C:/Users//AppData/Roaming/gnupg/gpg.conf' gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: enabled debug flags: extprog assuan gpg: DBG: chan_000000D4 <- # Home: C:/Users//AppData/Roaming/gnupg gpg: DBG: chan_000000D4 <- # Config: C:/Users//AppData/Roaming/gnupg/dirmngr.conf gpg: DBG: chan_000000D4 <- OK Dirmngr 2.1.1-beta35 at your service gpg: DBG: chan_000000D8 <- # Home: C:/Users//AppData/Roaming/gnupg gpg: DBG: chan_000000D8 <- # Config: C:/Users//AppData/Roaming/gnupg/dirmngr.conf gpg: DBG: chan_000000D8 <- OK Dirmngr 2.1.1-beta35 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_000000D8 -> KEYSERVER --clear hkps://hpks.pool.sks-keyservers.net gpg: DBG: chan_000000D8 <- OK gpg: DBG: chan_000000D8 -> KEYSERVER hkps://hkps.pool.sks-keyservers.net gpg: DBG: chan_000000D8 <- OK gpg: DBG: chan_000000D8 -> KS_GET -- 0x8BCF070743176C6A gpg: DBG: chan_000000D8 <- ERR 167772346 No keyserver available gpg: keyserver receive failed: No keyserver available gpg: DBG: chan_000000D8 -> BYE gpg: secmem usage: 0/32768 bytes in 0 blocks > References: > [0] > http://lists.gnupg.org/pipermail/gnupg-users/2014-November/051471.html Seems to me to be a slightly different issue. As a side-note: Inoticed error messages for missing directories and files: %appdata%/gnupg/trusted-certs/ %appdata%/gnupg/extra-certs/ %appdata%/gnupg/dirmngr_ldapservers.conf %appdata%/gnupg/ldapservers.conf I created those files and folders and placed a hardlink to the .pem-certificate in the trusted-certs folder. Regrads, Hugo From mail at robinmathewrajan.com Tue Nov 25 13:37:21 2014 From: mail at robinmathewrajan.com (Robin Mathew Rajan) Date: Tue, 25 Nov 2014 18:07:21 +0530 Subject: Setpref is not working or is it a bug or something? Message-ID: <54747801.7040102@robinmathewrajan.com> Hi all, I edited gpg.conf and set the parameters as like this: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 CAMELLIA128 AES CAST5 IDEA BZIP2 ZLIB ZIP personal-cipher-preferences AES256 CAMELLIA256 TWOFISH personal-digest-preferences SHA512 personal-compress-preferences BZIP2 And used 'setpref' to include those newly updated preferences to my existing GPG Key! I confirmed once again with 'showpref' if those preferences are set correctly. Saved the key and quit the GPG console. Using Kleopatra, I deleted my GPG Key and imported it from the backup. After the importing, when I checked if those earlier preferences are retained in the key, I got quite astonished. Those preferences are not retained. The output is like this. pub 4096R/47CF3842 created: 2014-09-21 expires: never usage: SCEA trust: ultimate validity: ultimate sub 4096R/9939A3DF created: 2014-11-22 expires: never usage: E sub 4096R/4DA179AE created: 2014-11-22 expires: never usage: S [ultimate] (1). Robin Mathew Rajan (https://www.robinmathewrajan.com/) [ultimate] (2) Robin Mathew Rajan (https://www.robinmathewrajan.com/) [ultimate] (1). Robin Mathew Rajan (https://www.robinmathewrajan.com/) Cipher: AES256, AES192, AES, CAST5, 3DES, IDEA Digest: SHA256, SHA1, SHA384, SHA512, SHA224 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify [ultimate] (2) Robin Mathew Rajan (https://www.robinmathewrajan.com/) Cipher: AES256, AES192, AES, CAST5, 3DES, IDEA Digest: SHA256, SHA1, SHA384, SHA512, SHA224 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Screenshot: http://pub.robinmathewrajan.com/GnuPG_Users_Mailing_List/GPG_Preferences.png Why this happening and what is the solution to it? I'm using Windows 7 SP1 and Gpg4win package. Thanks, Robin Mathew Rajan https://www.robinmathewrajan.com/ -------------- next part -------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFQfTSwBEACSpTQS8hUqQDZ0rALoicc2eqh9Hkk+O8VATzntNdhPNLkKtJLd 0pUHv3UskrxxB776E+CeWD8P6WYJPiX1vaMN3UlSzM92P7ANqzMMZ8qa4L5HeKvL IQdptbGFrkFXb/ITLWewphUYSrPG3YFTRz2tSjQHAzJmESI7wBxAB2nUbWxXFu01 xvGVC73tmeeWXrTa9qGAkFpjs127RUBiixShx6N5Stn+G6M9g/8TZHG+Y4hU44a3 xvrOYK75q6qVUStOlbfYJzNixsz3xP6mKPCpHaqqOXEpP2h9KKuxTGybkJsq6oeI jWW1MCcZ2xPyFoGib6IKMRY/lGiPFmEjrdmSEQVaynBE8BXaqxaMEHfholCYDS8u iNffmliLmUlTcCNvWxO66GEQwgekMr6cej6C5zCCKRjff4etyso+vIYK9rFf1vh5 HI0waIYvHkX0/YktCU9ldUvQG133Br5YpbHp9g/M2ZkC4U2uVKt9zn9S5XxND4i2 GZbNfi6Z+neAzIt26JSTEP/1WgmH6p8adMAMcCRssN404Ex5YDHMXiTtqrPo+Xio vdcJgX1SMbmOWi4a06gBtLc6/3KRCdCBX+w8Dy6kCCWPngSojnk77LKy+Jse5hEW Nr2RL6DL0/JLnqVzXRf5/Wp9B3DQIFf3DEX9hzuTzTMQXPaya5Dky8EjBwARAQAB tFNSb2JpbiBNYXRoZXcgUmFqYW4gKGh0dHBzOi8vd3d3LnJvYmlubWF0aGV3cmFq YW4uY29tLykgPHJvYmlubWF0aGV3cmFqYW5AeWFob28uY29tPokCOwQTAQIAJQIb LwIeAQIXgAUCVHJC3woLCQ0KCAwLBwMBBRUKCQgLBBYDAgEACgkQfTpsWkfPOEKU 2xAAj7nJ95YEbDuEcdpVTVhobixs8uCj/iB5wYvecwwXY8nS43lBq/5WV9Y5LNws ZVdtTT1ElDheemg96ODXyOwxtTQyaGsyljaRSm04puEfzLWCn3VZ10+8XjZV+jsX EwLOvgljVJRqAv/2G3qCCA9/qHwuIbmeocsiYhFeGcN96Snsb6zKpby+60AVXa4D 62VJ6mIlTxHw3mPkYcuyhLXE/MT7fqE7FHuWZMEGW4bcWlD3GzhI4sii6h72ZFEw Zdxnv5BbTrbt4iSZ2hpPgXc9RWV2ap+AEzbYJz3Ny0Gxn459CAGCHoyr6qtIei13 sp8CTx+JoJ3b0qc1dQdrB/a246FkEKCa93mgBrUpen4jVpSmU4GPmAusK6qUDP9B 4xw1AGO6qMQimWc4Y3RyIwep/5On2ItRhkH3qCH4Bh0gDD7AgWRVri2Gs/REIVw8 FvC5L/verlxZhZv0sAwJxqXJqXjZ7J/i8lJChaEJKGDagvmi4TjXbP7Xf2NBlaae 4sh3J4w3ZlRMfUtwTN14/CXaYhiVqKGGZ7ZRIDdNcm3CwbX4Pr6duXPfa7/LaiUv KRwgLL6D2QlyHXA9xU0sutocwEKkWp97EAYHaXpcbHpRJxB+xteQlygy3GZFaBTf ATY5g2AFfCheMnzxMheLw+7h0I4LNrFe+MVIkmlJEouMAJ20UlJvYmluIE1hdGhl dyBSYWphbiAoaHR0cHM6Ly93d3cucm9iaW5tYXRoZXdyYWphbi5jb20vKSA8bWFp bEByb2Jpbm1hdGhld3JhamFuLmNvbT6JAjsEEwECACUCGy8CHgECF4AFAlRyQuwK CwkNCggMCwcDAQUVCgkICwQWAwIBAAoJEH06bFpHzzhCFiIP/R8bd0j4DGQAR+82 IHo7cUZryPuWrbGPwRL8CucgctJ1XkKF5tnYoZEp0+M7iheG84ovJ1ugjF4RG4EI WCYl9+QB01WbeN9Id/N4EQVrYUH5j0mJQ98ogcQ7qx0CjN1uUgLUHaUDhDldI5Pb teOrY6Jl269CFz2YvttWPeUhO50HlpCLBfNzN9161Ws375Spw+PPfrRyu33SHFvA GcmUQzUufayDUfZvl1DDKfLE1gFtt6yEVdP9yXZxT3ztgrDxz+ZdPXwFQqEDcEX/ IZO79zPasiUJAo4RRZ6RY4Fr12tS/06uHmaHPBj2v11CdnQSdl8Jdyfc4UrcAtxc jPTSjHzc3txT7BtWVRqgtxAKxxobhQo9EIWNhgeLwPPch1BwNLXL4EeNDga1O3i/ YWo9+FK6JYYdQP6+jlXjDi2BKAmgARLKWyD4L9pscmgNln+/UMatuzY+vHKPMEAk dle6BpXPMLgab7ShF7I7fGz3LRKh1vbGg6MqrItOlPMrvsEBQPuPAZmYuZeTwugc 2KiEUIHElOsmE9+KETt98jny6d4rCNGbZNJAxvUJpm9YyWO2EzunvAXHdpeeUoW0 iliASFB60i4wzfsVU3PKgqPm7GQR6fGh0ALRDVdmAf4GHqY2wsqJPctpTCjadFre M6+ydHnLdJD0P4w87ZfxU6880uVKuQINBFRwQbIBEAC92QHNR6xIH0NfqZbk8vQP 2KnzGewc/wWIXHZbQArm3FYMhPYhA7me/A5c/c6SnjwzcxjLLKreVXo1nGNnOYKj yAa3QihqUOW26Upm+8IXXb7WN0kDDn0xZgNPMyIRyP0T2T8vgpHLVbkjB8joNZVu bo+kU/owqSKdPh3ehExTgXm0xtGYdD7sFKrCNAE9WA+0SI9ejU84GnpNJ6AlUIum mIr5769JZgff9IdcubtbzgDp+/tzrvBVGJv6rXWBQWPICutJVgyNx1faXbiB4y18 hFo6XgbSG4BQFX/c8BTn6n79OOi2nLQAMe9eoFdy/mSM+qrk7uDpqKtn/ydvcSz/ e+KgTmdl9gM33toO+le18dUiTeH8TR5LB1v0xcsBDMlnH5/8gMXmhPqMSELrvHC7 7yT26gkLL7VzFoM09qqmGKJlsreQ/HucyI74++Qo63J6w/mU6eijqsYDferMgMRp SVsbxGDtLdxObUucBJ21H/fmLT3yVbj3RqiJonymz2t1avRfeun327nxiAPnfl2X k6JRmSr9/PTZCTDLPPQC6eeMH2COINliFrSa6jcxE5SWTjvSWEavc3LcAmLgJ+84 ++cHCfhctX1ngRQ0ZULkyAtSHQVy+8W3cVqPrMfmo5YtVpjfdOczus52zGad1LN+ ElJtmCK6WFl2/102w2EEHQARAQABiQIfBBgBAgAJBQJUcEGyAhsMAAoJEH06bFpH zzhCNAcQAJD02/ibeP/ouFGoTmTgH/wsGQxYHGN0fQnkDjChTGHTLeVX01XarMdu ui9c0gNsotMT23FAjpjHmb8zkxr14QdeGH/tdG0XEjs2Tr57P7SWjTXol4qX+jlI mcaBXuujs9a1/1aM1w4f6DGTaYs23PLwZD8I8D0AbMMfh1tYdAsE/RJ00ffDhowv SuSvWWy37TyXVxAJu3k52LPVxRCd1xxiUL12enabkeyR8iaL4jtlN2KrG6rM2s+C sbh2R+EJiFQ/UX996h0QiUWVVxBXN4RQAZ9jiZzG5s8cS69+Pc2Hl32qjlsyrkN0 7S0KTgi9fRGwxOsyjh3JIkJaQjbfAl0Uben8GxhHDq1g7612BDPuj5/uatJBii0e oAaJmMuyVjZ7EwgA/v5vbwr27uAv9vzZ9YBw7CgzPdrPlJBsPDUhUzR9/kPGo+gQ Rlix+uasiM7Q3gzCApHDmwJviI5uk3aufdYl9BaHHXp7Xdd1bYal84MZIepr1oN+ 7rHOzfaPvhZr2BapmQYNaIKLSIGlj9N8V/kHote+X7/rpnjT5Hw74F/EwBrKFT2M lXS77fBH3J5k6vZbXlGoEnLfDkzSU2sv1J06FepEQsPUAj+41ZB6uuJAokPSkKfz fID6+ODmGLh8TOVRlVg/CzqjpBkEEXbrvO2KX0osIYnQFKxOayvtuQINBFRwRYcB EACvv2Yp3dDNw6xfHDK2kSLk29QzOnZRtHFFGxDEA5Pr0epyG5NvxJipn7RBm4Wt BYiG6KNOCWfKf+aqJXUQdopOXp2uAmhSkSboRdOGlcaTRc7vHlEKMGOLfySpwJdF QIL7lPq/f8qIB8iYCSeiP9Xz3XSkBA7mzF8wVSzm8Q1q9bXkCmXConjtWu+2pdww sIuxMik52MiUaqKMpG5t7pTZDSPFSGsIJkHpI7XzOW/Wvoj78Kx6SqIZjlQnI8nS wJ58AVYaiyn8P9f2u6CNnna2SlfiXjrX7Dl+Me5Js1E9MGxovZ6dBQt+7veHO0rC zbQjIC6ut+kPIQIW14rZxpzRODHcK54kfkSYmf/zIxaDZ7XxkyY4oVtZNq0Yz+My PPTFOkXEzNQGcV9zKqMX+uCJZx7zl1nxcezG0H/JyNvsAm4OISHS8ilH/x4Rd/x1 Ll+Lt2J5xPxY/ktyn+HKkCRJG3L4K4CZSA8rp2al72i6cAb9VovnxsPH7cbdwh69 Qf6RerODIzmlJs6lrCymprGa0C1Rf2XNICrRfnT6Y6k/AygpU/n21ViEqoGPKFad WZK11M6MGI3aRcIDf4H5VOFRSygaSNx3peqGxGQkiqKex/2zUvIdXVuNtZGqMh1t tQrbJw1dOnsIb+GeJnfLpR1Awa5SiD1G0zvsLCgzm8WuJQARAQABiQQ+BBgBAgAJ BQJUcEWHAhsCAikJEH06bFpHzzhCwV0gBBkBAgAGBQJUcEWHAAoJEJyRZAJNoXmu Sg0P/30thcf1aS6VxfBybFHAu8vR9VAhscjCpNZhq4AOsXu73SwgsTxhkZpcuyK8 5j2/h8o6i2HeDDVMsYk93s66ozG6l/tC6+Y02p7YohJ03kybVV96lRI3ScBsOhOt 8zQAF/05veLQz2vvzFrLhiQ6F9C+jzEPdEwC+w9qRGNmxe52QbpXS3FNaETlWKeU RwcN+pMKW/6rLoOSR7/vZyn+aJAFpPvGKb9V+vNzJzpp0GVed9G2MFDWG5wWAnTu wxSMT+DS6I9KJhyy4sZprzwKQGkqnTx5U+OQkREp8AuMXWqPcfbKIV/8GOyrO30Y Sl4ZjMalF600qRaTy7ewcuzFZUDhxDFR6iPDcsGG8JltKetNfb7TdOW45YuFCLXs WmbUM5MwvmNDK1P/YdlvlwRvpysbgYMw5lfoG5PUkIy++s2Z5p8Zj908wg3BTRXF YLl9cgDPXz7Myf6QcEHjcAA0E3exfhbXW/4WEPOVnKXtEXeGjsGTC/cao7udV3gI JZXbf5dSCGDUp5kCyrldvDGbrEEo29p8xS0qH6vwsmnej7dGB/zvnHrf8tkSZBit SAW2YILt8lwL8wBbYuWn0zB6iI2uZsIuBxln4zVRrZfbzV/Bl2IqqvNYbS9f+jTy +S3sPBo0klp0v9uK2/yiKY+VUWna7bKIz8B3f39hVCNg/fNZ2N4P/iyVfo14YZFK DKBe0qzNkg2I2/K2FGoGHAHLUc+d3EL4FgWqLh8OJ1ssmkdgyfEHf06GPitgTlEv jhuUs6xPEj5wkRn6Tyt9KRhn1AWKYGOoSWrAJ5e7dhbirI9CsvAGoigpCBm8bZJi I2kHT0VLAh3MQiGHsJF3OZcLrgMdGMU+BCB/vJzyZR6zu4Ge5FMhpqMUCU93IhwN PYH2nWv/z59toB7utYO4ZQd/ABAC217e6JE3Te+XNf92fJuVzljVYZ4e2gudMAsw 95WXAVcwvVrvzHyEI9GUC6D4QUCcXUKo1sOK0VSceOmnmgUTrVEicHEkY3xAGkVx UqeaXwr7DfupHaCJ/M+S2eCEF354kI3GNRCiDAA6eVDtCl1CsMDD74xWmhhb+G+r gtMz3jZFE+XdmwNfp03ilsMCbtwBWwmrKPCDYNhDWwJNlumQIJgsToBaxwHLPs8U KlFAn9t5t0hWale8A6YUFJWMzJ7YseSOsopSgiYEQVkrbeSOHvV7BHXodR5NB9XU jKAJKz/MaYo/7/HSVr5M7pcMMRSKMXDLukHMPwYwRXFX9GnCCpa93iyN5mI+0yvi w1fri48J5gCSEKYk4tAtPAHrGq1IMOiY0ViMm7h38YrQNoIllcdaZqz1M/9DgkBi pfq4IThP9uGrXqZoRBUR+S1/9ONkRVCf =4lTF -----END PGP PUBLIC KEY BLOCK----- From wk at gnupg.org Tue Nov 25 13:40:02 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Nov 2014 13:40:02 +0100 Subject: [Announce] [security fix] Libksba 1.3.2 for GnuPG released Message-ID: <87y4qzbgil.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.3.2 of Libksba. This is a *security fix* release and all users of Libksba should update to this version. Note that GnuPG 2.x makes use of Libksba and thus all user of GnuPG 2.x need to install this new version of libksba and at least restart the dirmngr process. Libksba is an X.509 and CMS (PKCS#7) library. It is for example required by the S/MIME part of GnuPG-2 (gpgsm and dirmngr). The only build requirement for Libksba itself is the libgpg-error package. There are no other dependencies; actual cryptographic operations need to be done by the user. Libksba is distributed under the LGPLv3+/GPLv2+. There are no user tools accompanying this software, thus it is mostly relevant to developers. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.3.2.tar.bz2 (587k) ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.3.2.tar.bz2.sig The SHA-1 checksum is 37d0893a587354af2b6e49f6ae701ca84f52da67 libksba-1.3.2.tar.bz2 Noteworthy changes in version 1.3.2 =================================== * Fixed a buffer overflow in ksba_oid_to_str. Impact of the security bug ========================== By using special crafted S/MIME messages or ECC based OpenPGP data, it is possible to create a buffer overflow. The bug is not easy to exploit because there only 80 possible values which can be used to overwrite memory. However, a denial of service is possible and someone may come up with other clever attacks. Thus this should be fix. Affected versions: All Libksba versions < 1.3.2 Background: Yesterday Hanno B?ck found an invalid memory access in the 2.1 branch of GnuPG by conveying a malformed OID as part of an ECC key. It turned out that this bug has also been in libksba ever since and affects at least gpgsm and dirmngr. The code to convert an OID to its string representation has an obvious error of not considering an invalid encoding for arc-2. A first byte of 0x80 can be used to make a value of less then 80 and we then subtract 80 from it as required by the OID encoding rules. Due to the use of an unsigned integer this results in a pretty long value which won't fit anymore into the allocated buffer. The actual fix for lib Libksba is commit f715b9e. Support ======= For help on developing with Libksba you should read the included manual and optional ask on the gnupg-devel mailing list [1]. A listing with commercial support offers for GnuPG and related software is available at the GnuPG web site [2]. The driving force behind the development of GnuPG is my company g10 Code GmbH. Maintenance and improvement of GnuPG and related software takes up most of my time. To allow me to continue this work, I kindly asks to either purchase a support contract, engage g10 Code for custom work, or to donate money: https://gnupg.org/donate/ Thanks ====== Thanks to Hanno B?ck for taking the time to run fuzzing tests on GnuPG and reporting them. Happy hacking, Werner [1] https://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] https://gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From hugo.hinterberger at gmx.net Tue Nov 25 14:03:41 2014 From: hugo.hinterberger at gmx.net (Hugo Hinterberger) Date: Tue, 25 Nov 2014 14:03:41 +0100 Subject: Beta for 2.1.1 available References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> Message-ID: Hello Werner, On Mon, 24 Nov 2014 09:24:28 +0100, Werner Koch wrote: > Bug reports please to the gnupg-users. When I try to open the Card Manager in GPA the program freezes. according to Process Manager there is something (not much, almost nothing) going on, but the UI does not respond any more. Another thing: when running gpa a series of console windows pop up and close before the UI appears. This is just a slight annoyance. Regards, Hugo From rjh at sixdemonbag.org Tue Nov 25 15:53:52 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 25 Nov 2014 09:53:52 -0500 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <54747801.7040102@robinmathewrajan.com> References: <54747801.7040102@robinmathewrajan.com> Message-ID: <54749800.8030806@sixdemonbag.org> > Why this happening and what is the solution to it? The preferences list in gpg.conf are your preferences for what you use for the mail you compose to others; the preferences list on your key are your preferences for what you'd like other people to use for the mail they compose to you. They represent two different things, which you seem to have conflated together. I think this will resolve a good half of your questions. The other half can be resolved by asking this question: "When I changed my key preferences, then deleted the key, and restored it from a backup I made before I changed my key preferences, how could the backup know about the changes I made *after* I made the backup?" :) From rjh at sixdemonbag.org Tue Nov 25 19:45:28 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 25 Nov 2014 13:45:28 -0500 Subject: Gpgma Message-ID: <5474CE48.40904@sixdemonbag.org> In some spare minutes while waiting for an airplane to arrive and my vacation to begin, I did a little more work on the key backup and migration tool that I mentioned on-list a while ago. It's still fairly simple, but there's a good side to simplicity: that also makes it hard to screw up. Major changes: 1. Switched over to Java, mostly for access to a good GUI toolkit[*] 2. Now there's a proper GUI on it 3. Better sanity-checking and error handling 4. Now on Github at https://github.com/rjhansen/gpgma If you've wanted to contribute some code to GnuPG but feel a little intimidated by the size of the codebase and the occasional hairiness of C, I hope you'll take a look at gpgma. It works, but there's a lot of stuff that could be done as well -- things from simple to complicated, like: * Adding a menu bar to make it look like a normal application (simple) * Improving error handling and error reporting (simple) * Making it able to recognize when it's given a corrupted/incomplete backup file (moderate) * Making it back up everything but random_seed, not just the absolutely necessary files (simple to moderate) * Use Eclipse/SWT to make it look native on all platforms (moderate) If you're interested I hope you'll check it out. From mail at robinmathewrajan.com Tue Nov 25 20:43:42 2014 From: mail at robinmathewrajan.com (Robin Mathew Rajan) Date: Wed, 26 Nov 2014 01:13:42 +0530 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <54749800.8030806@sixdemonbag.org> References: <54747801.7040102@robinmathewrajan.com> <54749800.8030806@sixdemonbag.org> Message-ID: <5474DBEE.1040404@robinmathewrajan.com> No bro. You got me wrong. :( I referred these two manuals before I made the change in gpg.conf. 1) https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html "--default-preference-list string Set the list of default preferences to string. This preference list is used for new keys and becomes the default for "setpref" in the edit menu." 2) http://www.gossamer-threads.com/lists/gnupg/users/51697 "Re: Difference between setpref and options in the configuration [In reply to] On Sun, Feb 9, 2014 at 2:39 PM, Stephane Bortzmeyer wrote: > When reading > , which > advises to use gpg --edit-key and setpref to choose "better" > algorithms, I told myself "Why risking forgetting the right > command-line when you can simply use the configuration file?" So, I > put this in ~/.gnupg/gpg.conf : > > # SHA1 by default > cert-digest-algo SHA256 > # Crypto preferences > personal-cipher-preferences AES256 AES192 AES128 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 > personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed > > And generated a key, with two UID. But it seems the preferences in > personal-*-preferences have been completely ignored: That's because the personal-*-preferences don't change the preferences in the key itself. They merely change the order of ciphers, hashes, and compression methods that you prefer when communicating with others (so long as you both support those algorithms). According to http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html you'll want to use "default-preference-list" followed by the list of preferences for your key. For example, putting "default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed" in your gpg.conf file and then generating a new key (or running "edit-key KEYID", "setpref" with an empty string for the preferences, and "save" on an existing key) will set the key preferences to that string. Cheers! -Pete" Those are the two manuals I mainly referred before editing the gpg.conf. The backup file was made after the changes made in the key. It's not made before I edited the gpg.conf and used setpref. The backup file is made after I used the setpref option. And that's why I'm confused about it. Even though the backup file was made after the changes made in the key, why the properties set by setpref are not included in the key? I'm confused. :( On 25-11-2014 PM 08:23, Robert J. Hansen wrote: >> Why this happening and what is the solution to it? > > The preferences list in gpg.conf are your preferences for what you use > for the mail you compose to others; the preferences list on your key are > your preferences for what you'd like other people to use for the mail > they compose to you. > > They represent two different things, which you seem to have conflated > together. I think this will resolve a good half of your questions. > > The other half can be resolved by asking this question: "When I changed > my key preferences, then deleted the key, and restored it from a backup > I made before I changed my key preferences, how could the backup know > about the changes I made *after* I made the backup?" > > :) > From wk at gnupg.org Tue Nov 25 21:38:43 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Nov 2014 21:38:43 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <201411250942.17695.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 25 Nov 2014 09:42:07 +0100") References: <201411241001.38899.bernhard@intevation.de> <20141124092453-16648-55173-mailpile@slinky> <201411250942.17695.bernhard@intevation.de> Message-ID: <87mw7f817w.fsf@vigenere.g10code.de> On Tue, 25 Nov 2014 09:42, bernhard at intevation.de said: > Oh, what about the idea to just ship a MIME parser with GnuPG. >;) tools/gpgparsemail is such a thing. It translates a MIME structure in something easier to process with standard Unix utilities. Mainly a debugging tool but the code served well as the basic for the MIME parser in GpgOL. > with an option that the user can fall back to a zipped and encrypted > (gpg-zip/gpg-tar compatible format) attachment, FWIW, this is the same. PGP named their tool pgpzip but it actually creates a tarball. gpgtar does the same and has mainly be written due to the problems of porting a shell script making use of tar (gpg-zip) to Windows. > disassemble them to put the together again when they are needed. In this > process they strip whitespaces, headerlines and reformat linebreaks. > So there is a designed loss of information in the library. Using Evolution as an example has never been a good idea. [1] > To me that is a design issue of the library. And I believe most other MIME > libraries will not share it. Beware of the camels ;-) > which are to be assumed identical, you may introduce an attack surface > because some clients may display the contents slight differently. A clever > attacker may exploit this to play tricks on the user. Recall the attacks which used to be mounted on text based MUAs: Including of faked verification message at the top of the message. This required the MUAs to display the current wall time right above the message so that the user had a chance to detect faked signed messages. MIME is a well thought out system to markup mails; it should always be used. > envelope subject). In total I would say that having an envelope subject is > good anyway and that most email clients would continue to display it, because > it could contain important information still. We need it for public mailing lists anyway. But it is a non-issue, a MUA could simply replace the subject by something innocent. But does anyone really believe this would help to increase the number of encrypted mails? > I'd say you are slightly unlucky with pythons "email" library. Replace that by a custom one - writing a MIME parser is easy. 1200 lines C and for sure much less in a high level language. Shalom-Salam, Werner [1] It used to do to signatures what this record intro did to English 40 years ago: Hhmm, ah, hello my dear friends. Here I am again with my music. Well, it's very nice that I can speak to you now from this very fine record. And I am freuing me, that you are freuing you to hear my voice again. Isn't it nice? Yes it is. Well, I want you to listen to my very new song, wich I have brought along from a trip through Africa. And I hope, you like it. Do you like it? Yes, you do. And also here are ebenfalls some of my very best friends, which will sing along together with me. Come on boys, let's sing that the camels are breaking together. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From 2014-667rhzu3dc-lists-groups at riseup.net Wed Nov 26 00:55:11 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Tue, 25 Nov 2014 23:55:11 +0000 Subject: Encryption on Mailing lists sensless? In-Reply-To: <1796158353.20141122214709@my_localhost> References: <20141118173033xCi55Ehu8G@goodcrypto.com> <546B8CDD.5010700@riseup.net> <448302142.20141118224318@my_localhost> <59025860.IpMIFAe70I@collossus.ingo-kloecker.de> <1796158353.20141122214709@my_localhost> Message-ID: <276866013.20141125235511@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 22 November 2014 at 9:47:09 PM, in , MFPA wrote: > I don't know how Thunderbird+Enigmail handles this. Having asked the question on PGPNET, I am told that Thunderbird+Enigmail warns that users of some PGP Corp. products won't be able to decrypt if they are BCC recipients. If you ignore the warning, all BCC recipients' keys are included in the encryption list. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net One morning I shot an elephant in my pajamas. How he got in my pajamas, I don't know. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlR1FuZXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pwFIEALSzVk3hwiYbeuq90UEyWXfbRf0wPrsoZH03 uaRqxnKtaohAISVRw7LxtPcmwAcQZjJIZlE0FlsglN86ekSF9g7Cr2k6r7NX/SZp LjCvTI7z1uP6Tt+gewl6BMk8YRrcASdobGUS79EvzD3Q7+zKH0E9aoD9+8ZPzV4v qUCylV4FiQF8BAEBCgBmBQJUdRbmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwS8sH/RycmjdK8AfvzsS9 XlvfKnunVXMUcf+qyIL+UsKRjP1WCSLkgzHLgeva931xwy5SvnxGGyQuU1SY37VY uJR2dEUadY47+zJfCudYkodd3ETxpLT7MVqc8gr7BXoU8HYsl4hYGssHENoY464h gUQEj5EUj2AqNiS6gjyNID+puiiXfLlyrFKC8aXtwFVW2ViKNUNK6OfTNBSm6fjM sFo8YWB3RWfO6TwEwgIXwncflcuBq+zEqJf/5xHjxTNDckumQhIb3n7wO5CaGUap q6RuM4f2Oa8O0dddxb89EoxzOlbfSxRwIT409fzI5CmcHbajt1P52Tp7wVCJd/Y/ gaZWx8g= =BiJx -----END PGP SIGNATURE----- From gnupgpack at on.yourweb.de Wed Nov 26 08:19:01 2014 From: gnupgpack at on.yourweb.de (gnupgpack at on.yourweb.de) Date: Wed, 26 Nov 2014 08:19:01 +0100 Subject: Setpref is not working or is it a bug or something? Message-ID: <22BD94.54758CF6.0001@gate> Hello, beware of compatibility issues... Older versions of Debian (< sarge) don't support SHA512, AFAIK. Many Smartcards are limited to key size <= 3072 bit, AFAIK. RSA signatures are larger than DSA signatures, even if same bit size. So, what are the most useful cross-over compatibility settings for new, secure keys? Regards, @g. > -----Original Message----- > From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of > Robin Mathew Rajan > Sent: Tuesday, November 25, 2014 8:44 PM > To: Robert J. Hansen; gnupg-users at gnupg.org > Subject: Re: Setpref is not working or is it a bug or something? > > No bro. You got me wrong. :( > > I referred these two manuals before I made the change in gpg.conf. > > 1) https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric- > Options.html > > "--default-preference-list string > Set the list of default preferences to string. This preference list is > used for new keys and becomes the default for "setpref" in the edit menu." > > 2) http://www.gossamer-threads.com/lists/gnupg/users/51697 > > "Re: Difference between setpref and options in the configuration [In reply > to] > On Sun, Feb 9, 2014 at 2:39 PM, Stephane Bortzmeyer > wrote: > > When reading > > , which > > advises to use gpg --edit-key and setpref to choose "better" > > algorithms, I told myself "Why risking forgetting the right > > command-line when you can simply use the configuration file?" So, I > > put this in ~/.gnupg/gpg.conf : > > > > # SHA1 by default > > cert-digest-algo SHA256 > > # Crypto preferences > > personal-cipher-preferences AES256 AES192 AES128 > > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 > > personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed > > > > And generated a key, with two UID. But it seems the preferences in > > personal-*-preferences have been completely ignored: > > That's because the personal-*-preferences don't change the preferences > in the key itself. They merely change the order of ciphers, hashes, > and compression methods that you prefer when communicating with others > (so long as you both support those algorithms). > > According to http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG- > Esoteric-Options.html > you'll want to use "default-preference-list" followed by the list of > preferences for your key. For example, putting > "default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > CAST5 ZLIB BZIP2 ZIP Uncompressed" in your gpg.conf file and then > generating a new key (or running "edit-key KEYID", "setpref" with an > empty string for the preferences, and "save" on an existing key) will > set the key preferences to that string. > > Cheers! > -Pete" > > Those are the two manuals I mainly referred before editing the gpg.conf. > > The backup file was made after the changes made in the key. It's not made > before I edited the gpg.conf and used setpref. The backup file is made > after I used the setpref option. > > And that's why I'm confused about it. Even though the backup file was made > after the changes made in the key, why the properties set by setpref are > not included in the key? I'm confused. :( > > > > On 25-11-2014 PM 08:23, Robert J. Hansen wrote: > >> Why this happening and what is the solution to it? > > > > The preferences list in gpg.conf are your preferences for what you use > > for the mail you compose to others; the preferences list on your key are > > your preferences for what you'd like other people to use for the mail > > they compose to you. > > > > They represent two different things, which you seem to have conflated > > together. I think this will resolve a good half of your questions. > > > > The other half can be resolved by asking this question: "When I changed > > my key preferences, then deleted the key, and restored it from a backup > > I made before I changed my key preferences, how could the backup know > > about the changes I made *after* I made the backup?" > > > > :) > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Wed Nov 26 09:48:09 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 09:48:09 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124132331-16648-17477-mailpile@slinky> (Bjarni Runar Einarsson's message of "Mon, 24 Nov 2014 13:24:01 -0000") References: <87ppcceo8f.fsf@vigenere.g10code.de> <20141124132331-16648-17477-mailpile@slinky> Message-ID: <87oaru73g6.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 14:24, bre at pagekite.net said: > Similarly, when generating messages I had to fork the Python lib's > generator and disable various "helpful" hacks that were randomly Hmmm, one more reasons for me to start writing a gpgsendmail tool to create encrypted or signed mails with attachments and that all. Doing this with a script and sendmail is possible but it comes to problems if you need to insert user data which might reqyuired a different encoding. > You want to verify that the message composed by the user did not > change - the technicalities of the container it is placed in could > well have been considered out of scope. Requiring that white space > placement and irrelevant things like boundary strings stayed unchanged > is unnecessary and in practice counterproductive because it tightly You can do messy things by changing boundary strings, for example to bypass DKIM. If a message including attachments is signed you do not want that anything changes. And some people actually use the boundary as a side-channel (check mine) ;-). I agree that things could be done easier by rewriting the boundary - but it will end up with a chain of other changes you need to allow, for example you also need to change the Content-Type to identify the new boundary and why not also fix other things in this header, where to stop. All too complicated. Better don't touch any signed stuff. > It would be far, far more useful to have a signature for each part so > instead of a binary pass/fail, you get a more granular result saying > "Message body was fine", "Attachment 2-5 are fine", and "Something Too complicated and allows for replacement-attacks: Split a signed message and replace one attachment (e.g. a document with the price list) by an earlier version. Or remove one attschment. PGP uses this to get around Outlook problems ("partitioned mail" or so) but they knew that it has its limitations. > That is basically the kind of workflow my proposal emulates, is > compatible with and attempts to improve upon. Early kmail versions did the same. > way it can validate contents and structure, and also transmit headers we > would like to omit from the public RFC2822 header - without assuming or > imposing anything about the low level technical structure of the MIME MIME, is 22 years old and thus a year older than the first graphical web browser (Mosaic) which is believed to gave birth of the non-academic Internet. We have seen generations of different software hypes come and go but still some dislike to properly implement an easy and good way to partition data. I don't get it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 26 09:57:36 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 09:57:36 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124090351.5e0ec147@scorpio> (jerry@seibercom.net's message of "Mon, 24 Nov 2014 09:03:51 -0500") References: <201411241001.38899.bernhard@intevation.de> <20141124092453-16648-55173-mailpile@slinky> <87ppcceo8f.fsf@vigenere.g10code.de> <20141124090351.5e0ec147@scorpio> Message-ID: <87k32i730f.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 15:03, jerry at seibercom.net said: > On Mon, 24 Nov 2014 14:12:48 +0100, Werner Koch stated: > >> To be fair, that changed with Outlook 2010. We merely had not the >> resources to change GpgOL to make use of the new Outlook structure. > > Interesting; has there been any movement on that front? I use Outlook 2013 at > my office and that would be a handy feature to have. No. The plan was to setup a small project to see whether this will really work and only if the answer is yes to go for a real implementation. I once had a telco with the German BSI and the Microsoft Outlook managers and the outcome was the answer will likely be yes. However, having seen all the problems with Outlook development, I was not willing to go for a full development contract with the risk that due to unforeseen problems I would not have been able to deliver. Thus the idea with a first step research project - which is up in the air for 2 or 3 years now. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 26 10:08:03 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 10:08:03 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141124204810-16648-55252-mailpile@slinky> (Bjarni Runar Einarsson's message of "Mon, 24 Nov 2014 20:48:39 -0000") References: <9091c166-91b9-433a-8496-c53c6bf5d089@email.android.com> <20141124204810-16648-55252-mailpile@slinky> Message-ID: <87fvd672j0.fsf@vigenere.g10code.de> On Mon, 24 Nov 2014 21:48, bre at pagekite.net said: > 1. Mail clients have user interfaces that are at least somewhat > optimized for conversations, like the one we are having now. Moving the > text part into a container (rfc2822 or otherwise) breaks that flow for > everyone. Right. However, we, who raised up in a mail based discussion culture, tend to use free software MUAs and thus it will be easy to fix them for that case. All the others anyway top post and don't quote. Thus the extra container should not add many extra problems. > how the mail client is most often used. It is still an extra step > though, and extra code to write in the MUA, which is one of the reasons > I not sure about the merits of using a container at all. Save, right click, unzip/decrypt, read. From what I have see a pretty common workflow at least on Windows. > Note that if the container is a ZIP file, that will work without extra > tools on all modern OSes (if I recall, I need to double-check a fresh > Windows install), but that is certainly not true for RFC2822 or tar They also open mail box files (.eml) without any problems. > As stated in my post - my proposal makes life marginally worse for > people with PGP/MIME compliant MUAs (working with attachments becomes > less fun), but better for everyone else. I haven't come up with a way > around that yet, short of shipping 2 of everything in each message. :-) Everyone else is not signed or encrypting. They need to install new software anyway - why not do the right thing? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Nov 26 11:45:45 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 11:45:45 +0100 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <22BD94.54758CF6.0001@gate> (gnupgpack@on.yourweb.de's message of "Wed, 26 Nov 2014 08:19:01 +0100") References: <22BD94.54758CF6.0001@gate> Message-ID: <8761e25jfq.fsf@vigenere.g10code.de> On Wed, 26 Nov 2014 08:19, gnupgpack at on.yourweb.de said: > Many Smartcards are limited to key size <= 3072 bit, AFAIK. No. The 2.0 cards from ZeitControl all support 4096 (if you feel a need for this). The problem was that old GnupG versions limited them to 3k. > So, what are the most useful cross-over compatibility settings for new, > secure keys? Use the defaults and ignore the suggestions you find out in the wild. They are not useful for non-experts and are described for a reason in the "Esoteric" section. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupgpack at on.yourweb.de Wed Nov 26 12:14:43 2014 From: gnupgpack at on.yourweb.de (gnupgpack at on.yourweb.de) Date: Wed, 26 Nov 2014 12:14:43 +0100 Subject: Setpref is not working or is it a bug or something? Message-ID: Hello, > No. The 2.0 cards from ZeitControl all support 4096 (if you feel a need > for this). The problem was that old GnupG versions limited them to 3k. I am working with GnuPG-Pack, which includes extended gpg-1.4.18. This versions supports smartcard keys with 4096bit? >> So, what are the most useful cross-over compatibility settings for new, >> secure keys? > Use the defaults and ignore the suggestions you find out in the wild. What's about the standard SHA1 hash with signatures? In gpg.conf really no need for: s2k-count 1000000 s2k-digest-algo SHA256 s2k-cipher-algo AES256 cert-digest-algo SHA256 digest-algo SHA256 personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 personal-compress-preferences ZLIB BZIP2 ZIP default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 TWOFISH AES192 AES CAST5 ZLIB BZIP2 ZIP ??? Thanks a lot, regards @g. *still learning...* From wk at gnupg.org Wed Nov 26 12:27:21 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 12:27:21 +0100 Subject: Security Devroom @ FOSDEM'15 Message-ID: <87sih642xy.fsf@vigenere.g10code.de> Hi, I have been asked to forward the CFP below. In case we want to do a GnuPG BoF we should ask whether it is possible to share that devroom. Shalom-Salam, Werner ==== CFP: Security Devroom @ FOSDEM'15 AKA "Hardware and Software isolation mechanisms" Next FOSDEM [1] will, again, have a security devroom, this time on the topic of "Hardware and Software isolation mechanisms". We'd like to invite submissions of talks and presentations from developers, security researchers and other interested representatives of open source and free software and hardware projects. This is the call for talks and presentations that will take place in the Security devroom at FOSDEM 2015. Our topic this year: As complex software tends to have bugs, methods to contain the damage from a potentially serious bug (e.g., code injection, leak of memory contents) are required. While such methods have been known and available for a long time (HSMs and smart cards, privilege separation), it is surprising that an attack like heartbleed required the revocation of the private keys of a large part of the Internet. For that reason Hardware and Software isolation mechanisms that could mitigate such attacks, are again on the line, and the main theme of this devroom. For up-to-date submission and event information: https://github.com/security-devroom/fosdem-2015 The security devroom will be held on Sunday 1st of February 2015 in Brussels, Belgium at ULB room S.AW1.120 from 09:00 to 17:00. I kindly ask you to forward this announcement to any relevant FOSS project mailing list. [1] https://fosdem.org/2015/ [2] https://github.com/security-devroom/fosdem-2015 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bre at pagekite.net Wed Nov 26 12:58:03 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 26 Nov 2014 11:58:03 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <87fvd672j0.fsf@vigenere.g10code.de> References: <87fvd672j0.fsf@vigenere.g10code.de> Message-ID: <20141126113854-14202-36218-mailpile@slinky> Hi all, Thanks for all the feedback. My take-aways so far are: 1. People like PGP/MIME, there's zero interest here in replacing it 2. I need to spec out more clearly how the Manifest works - the questions/concerns show I have not communicated my ideas clearly enough My next steps on this will probably be: 1. Spec out the Manifest properly 2. Draft an implementation where the Manifest is used alongside PGP/MIME (not instead of) - think of it as an additional signature which also covers parts of the RFC822 header. ;-) 3. Come back here when I have something more concrete In case folks were wondering, Mailpile currently defaults to PGP/MIME when messages have attachments, but uses inline signatures/encryption when there is only a text message to send. This is done to improve compatibility with lame MUAs/plugins. It's configurable, but the setting is not exposed in the default user interface at the moment. The Manifest probably won't change that in the near future, unless I get some solid data to back up the concerns I've outlined in the post and here. Cheers, and thanks for GnuPG! - Bjarni -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From hugo.hinterberger at gmx.net Wed Nov 26 14:19:09 2014 From: hugo.hinterberger at gmx.net (Hugo Hinterberger) Date: Wed, 26 Nov 2014 14:19:09 +0100 Subject: Beta for 2.1.1 available References: <87sih9gg5f.fsf__20667.9045958028$1416817649$gmane$org@vigenere.g10code.de> Message-ID: Hi, On Mon, 24 Nov 2014 09:24:28 +0100, Werner Koch wrote: > Bug reports please to the gnupg-users. While executing a gpgsm --list-keys i noticed the following: fingerprint: 9C:E2:38:44:6A:8E:gpgsm: conversion from 'utf-8' to 'CP850' failed: Illegal byte sequence 4A:63:18:93:7C:41:62:7B:D0:E0:7A:86:44:87 Regards, Hugo From wk at gnupg.org Wed Nov 26 14:31:13 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Nov 2014 14:31:13 +0100 Subject: Setpref is not working or is it a bug or something? In-Reply-To: (gnupgpack@on.yourweb.de's message of "Wed, 26 Nov 2014 12:14:43 +0100") References: Message-ID: <87mw7e3x7i.fsf@vigenere.g10code.de> On Wed, 26 Nov 2014 12:14, gnupgpack at on.yourweb.de said: > I am working with GnuPG-Pack, which includes extended gpg-1.4.18. Sorry, I don't known GnuPG-Pack. > s2k-count 1000000 Better use GnuPG-2 which uses a values suitable for the machines on which you generated the key or change the passphrase. (i.e. 100ms) > s2k-digest-algo SHA256 > s2k-cipher-algo AES256 Why? I doubt that those who suggest that have a lot of experience in selecting algorithms. > cert-digest-algo SHA256 Okay, if you feel that your old GnuPG version benefits from this. > digest-algo SHA256 May break compatibility because it overrides the preference system. > personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 > personal-compress-preferences ZLIB BZIP2 ZIP Do what ever you like here. But why preferring ZLIB over BZIP2? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bre at pagekite.net Wed Nov 26 15:30:34 2014 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 26 Nov 2014 14:30:34 -0000 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <87oaru73g6.fsf@vigenere.g10code.de> References: <87oaru73g6.fsf@vigenere.g10code.de>, <20141126133816-14202-25655-mailpile@slinky> Message-ID: <20141126143034-14202-60524-mailpile@slinky> Hello! I just couldn't resist the chance to play devil's advocate some more... ;-) (Werner: Sorry about the duplicate, I fat-fingered the reply-all) Werner Koch wrote: > > It would be far, far more useful to have a signature for each part so > > instead of a binary pass/fail, you get a more granular result saying > > "Message body was fine", "Attachment 2-5 are fine", and "Something > > Too complicated and allows for replacement-attacks: Split a signed > message and replace one attachment (e.g. a document with the price list) > by an earlier version. Or remove one attschment. PGP uses this to get > around Outlook problems ("partitioned mail" or so) but they knew that it > has its limitations. My proposal doesn't have this problem. I want the manifest to summarize the entire content of the message, including sha256 (or whatever is considered good) fingerprints of each part. If you replace any parts, that is detected. You can delete the Manifest too, but my proposal included mitigation strategies for that as well. As mentioned in my last mail, I need to write a clearer proposal and flesh out the Manifest format a bit more. ... Elsewhere in this thread, I think someone briefly touched upon security risks imposed by Bad People messing with the MIME structure. I'm not finding it now that I go looking, so maybe I mis-read. But I'd like to discuss some of the negative security implications of PGP/MIME anyway, just for fun. :-) For context, I spent 6 years working in anti-virus/anti-spam for e-mail, and longer working as a sysadmin in various plaes. My understanding of the A/V industry and sysadmin mentality, is the sysadmin looove centralized solutions. They like to put security scanning tool on the mail server, where they are easy to manage and keep up to date, and don't need to worry about which MUAs and operating systems are in use within the org. You can even outsource that stuff, get your mail scanned as by 3rd party experts. Now, if your MIME library is just the right kind of shitty, and can be exploited by sending a nasty boundary, then PGP/MIME encrypting the exploint guarantees it will be delivered intact and undetected by the security scanners. Oops! This particular vector is admittedly probably rare these day. Hopefully most MIME parsers were fuzzed and fixed long ago, except for the new one that Werner wants to write in 1000 lines of C. :-P Hey has anyone fuzzed the plugins lately? Either way, this illustrates an important point. This fact is, if everyone encrypts end-to-end as favoured by this community, then it becomes impossible (or rather, pointless) to deploy centralized security solutions. If I were a paranoid sysadmin, I'd be tempted to reject incoming PGP/MIME mail outright, for this reason alone. In reality, directly mailing you an encrypted exploit is far easier than intercepting your legitimate mail and injecting exploits into mail other people wrote. Security is all about economics, and I'll boldly argue that PGP/MIME is not thwarting any real intrusions by protecting the MIME structure. And if we further factor in viruses and phishing and exploits and spam, then widely deployed PGP/MIME might make the real world less secure, not more. :-P If on the other hand, we encrypt just user-generated content and leave all the technical envelope crap exposed (including enough metadata to allow enforcement of content policies, e.g. banning .exe attachments), then we can play nice with the rest of the security eco-system. That sort of thing does have value... And I've just talked myself into leaking a bit more metadata, not less. Fun times! :-) - Bjarni -- I make stuff: www.mailpile.is, www.pagekite.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From dkg at fifthhorseman.net Wed Nov 26 17:37:01 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Nov 2014 11:37:01 -0500 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <22BD94.54758CF6.0001@gate> References: <22BD94.54758CF6.0001@gate> Message-ID: <547601AD.9040808@fifthhorseman.net> On 11/26/2014 02:19 AM, gnupgpack at on.yourweb.de wrote: > Older versions of Debian (< sarge) don't support SHA512, AFAIK. If anyone is running debian sarge (or even lenny, which came after sarge), they have other problems. Those versions of the debian operating system have not been maintained for years, and i'm sure that there are outstanding critical bugs in that software. We should not avoid anything for the sake of compatibility if "Debian (< sarge)" is the main concern. The onus should be on people running those systems connected to the modern network to deal with their own problems. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From ndk.clanbo at gmail.com Wed Nov 26 18:14:07 2014 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 26 Nov 2014 18:14:07 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141126143034-14202-60524-mailpile@slinky> References: <87oaru73g6.fsf@vigenere.g10code.de>, <20141126133816-14202-25655-mailpile@slinky> <20141126143034-14202-60524-mailpile@slinky> Message-ID: <54760A5F.7090302@gmail.com> Il 26/11/2014 15:30, Bjarni Runar Einarsson ha scritto: > And if we further factor in viruses and phishing and > exploits and spam, then widely deployed PGP/MIME might make the real > world less secure, not more. :-P Maybe including a mandatory proof-of-work that includes addressee identity might mitigate at least the spam? BYtE, Diego. From aathalye at mit.edu Wed Nov 26 16:59:20 2014 From: aathalye at mit.edu (Anish Athalye) Date: Wed, 26 Nov 2014 10:59:20 -0500 Subject: Security patches and gpg 1/2 development Message-ID: Hi, What is the right place to send patches for and discuss security issues in gpg? The gpg-devel mailing list? Or directly to some particular person? Also, are there two different repositories for gpg 1/2 development? How exactly is that organized? Thanks, Anish From dkg at fifthhorseman.net Wed Nov 26 19:59:51 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Nov 2014 13:59:51 -0500 Subject: Security patches and gpg 1/2 development In-Reply-To: References: Message-ID: <54762327.4000008@fifthhorseman.net> On 11/26/2014 10:59 AM, Anish Athalye wrote: > What is the right place to send patches for and discuss security issues in gpg? The gpg-devel mailing list? Or directly to some particular person? patches should go to gnupg-devel at gnupg.org, or to a bug report if you file one here: https://bugs.g10code.com/gnupg/index Hopefully Werner can weigh in on what to do if you have a sensitive security issue that you want to embargo (this should probably also be added somewhere prominent on https://www.gnupg.org/) > Also, are there two different repositories for gpg 1/2 development? How exactly is that organized? they're all branches in one repository: git clone git://git.gnupg.org/gnupg.git and take a look at: git branch -a You might also be interested in some of the info here: http://git.gnupg.org/ Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Nov 26 20:15:51 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 26 Nov 2014 20:15:51 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <20141126143034-14202-60524-mailpile@slinky> References: <87oaru73g6.fsf@vigenere.g10code.de>, <20141126133816-14202-25655-mailpile@slinky> <20141126143034-14202-60524-mailpile@slinky> Message-ID: <547626E7.6030304@digitalbrains.com> > My proposal doesn't have this problem. I want the manifest to summarize the > entire content of the message, including sha256 (or whatever is considered > good) fingerprints of each part. 1) What does a checksum add beyond the OpenPGP Modification Detection Code (MDC)? 2) Why doesn't an attacker replace the checksum? Anyway, if you really care about your recipient getting what you sent, you should simply sign, IMHO, due to 2). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Nov 26 20:15:59 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 26 Nov 2014 20:15:59 +0100 Subject: digest-algo SHA256, SHA-1 attacks (was: Setpref is not working or is it a bug or something?)) In-Reply-To: <87mw7e3x7i.fsf@vigenere.g10code.de> References: <87mw7e3x7i.fsf@vigenere.g10code.de> Message-ID: <547626EF.9010103@digitalbrains.com> (By the way, how did the topic - gpg.conf: settings for security and compatibility ever get confused with the topic - Setpref is not working or is it a bug or something? because this definitely is the former but is called the latter. Also, @g, as you apparently call yourself, you seem to start a new thread with each post, could you try to get your e-mail client to properly thread?) On 26/11/14 14:31, Werner Koch wrote: >> digest-algo SHA256 > > May break compatibility because it overrides the preference system. > >> personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 >> personal-digest-preferences SHA512 SHA384 SHA256 SHA224 >> personal-compress-preferences ZLIB BZIP2 ZIP Wouldn't personal-digest-preferences be completely redundant when you also specify digest-algo? It's going to force usage of SHA-256 anyway. Now about SHA-1 for signatures on data (/not/ certifications). As long as you sign only things you produced yourself, one would generally need a preimage attack on SHA-1 to fake your signature. There are currently no practical preimage attacks on SHA-1. The attacks on SHA-1 that are the buzz these days are collision attacks. But this is *only* a risk if the attacker can get you to sign a document the attacker created! If you are in the habit of signing binary documents (say, a Microsoft Word file or an OpenDocument file), then it might in the future become possible to involve you in a chosen-prefix collision attack and fake your signature. That is because there is more in such a file than meets the eye. You think you sign what meets the eye, you don't see the cruft appendage in that file that was cleverly included to create a chosen-prefix collision. This is what it would look like: Company Alice gives the contract for job X to company Bob, Inc. erfhwGqid389547854ddssdwiAQWQuibidfvsdf However, you wouldn't see that last bit because it is included in such a way into the file that it doesn't appear on your screen. Still, it is part of what you sign. The cruft at the end has the purpose to create a hash collision, and the whole document hashes to b843e5fb9ccef0091fa3e65d2ff349fcb46a6061, which is what you sign. Now, the attacker has created a second message in tandem, which reads: Company Alice gives the contract for job X to company Mallory. erfuihrhiwefbwu2347847834sdvbsduBHUIuygvuiUIHUI323432 They created this in tandem with his first message, and the cruft at the end is chosen carefully such that this again hashes to b843e5fb9ccef0091fa3e65d2ff349fcb46a6061.[1] And again, the cruft at the end is hidden in the file and doesn't show when you view the document. Now they can copy your signature, because you signed that hash. In practice, there are still several problems, such as the time of the signature being part of the hash and thus not fully under attacker control. It's just a rough sketch of the problem to give you a feeling for it. The message behind it is: unless an attacker can get you to sign something the attacker produced, you don't have to worry about collision attacks. If you use the same key for certifications and data signatures, then I think a certification is in the category "sign something the attacker produced", though. Has something like randomized hashing[2] been considered by the OpenPGP standardization people? Peter. [1] no, it doesn't, I can't do SHA-1 collisions, I'm sorry :) [2] for example http://webee.technion.ac.il/~hugo/rhash/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From ndk.clanbo at gmail.com Wed Nov 26 20:31:49 2014 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 26 Nov 2014 20:31:49 +0100 Subject: digest-algo SHA256, SHA-1 attacks In-Reply-To: <547626EF.9010103@digitalbrains.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> Message-ID: <54762AA5.8080302@gmail.com> Il 26/11/2014 20:15, Peter Lebbing ha scritto: > Has something like randomized hashing[2] been considered by the OpenPGP > standardization people? Well, IIUC with rhash you're giving the attacker another mean to tamper with your message. Unless 'r' is chosen deterministically. But then it can be predicted and could be accounted for... Maybe it could be more effective to use two different hash functions, one to generate 'r' and the other on the result? BYtE, Diego From david at gbenet.com Wed Nov 26 20:37:35 2014 From: david at gbenet.com (david at gbenet.com) Date: Wed, 26 Nov 2014 19:37:35 +0000 Subject: Update Message-ID: <54762BFF.8010409@gbenet.com> Hi Al, As so many have been aware, I tried LUbuntu amd64 LXDE with Thunderbird and Enigmail - which singularly failed to sign or even encrypt. I made add that Kleopatra Kgpg GPA also failed to work. As some of you are stuck with the mind-set that the earth is flat eg "Oh it works for me therefore it works for everyone else" is delusional. As stated I'd not ask 98 per cent of you to change a light bulb. I have now installed Debian release (wheezy) 64-bit and icedove 31.20 with Enigmail 1.72. Considering that icedove is Thunderbird and the same version as is Enigmail - I am at a loss to explain the failings. I just copied folders and files over with no problems. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Nov 26 20:39:33 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 26 Nov 2014 20:39:33 +0100 Subject: digest-algo SHA256, SHA-1 attacks In-Reply-To: <54762AA5.8080302@gmail.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> Message-ID: <54762C75.6080607@digitalbrains.com> On 26/11/14 20:31, NdK wrote: > Well, IIUC with rhash you're giving the attacker another mean to tamper > with your message. Unless 'r' is chosen deterministically. 'r' is randomly generated for each signature by the /signing/ party. So the attacker loses control over the input to the hashing algorithm, and they no longer can use collision attacks because they don't know the exact input to the hashing algorithm. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From tristan.santore at internexusconnect.net Wed Nov 26 20:52:59 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Wed, 26 Nov 2014 19:52:59 +0000 Subject: Update In-Reply-To: <54762BFF.8010409@gbenet.com> References: <54762BFF.8010409@gbenet.com> Message-ID: <54762F9B.4050507@internexusconnect.net> On 26/11/14 19:37, david at gbenet.com wrote: > Hi Al, > > As so many have been aware, I tried LUbuntu amd64 LXDE with Thunderbird and Enigmail - which > singularly failed to sign or even encrypt. I made add that Kleopatra Kgpg GPA also failed to > work. > > As some of you are stuck with the mind-set that the earth is flat eg "Oh it works for me > therefore it works for everyone else" is delusional. As stated I'd not ask 98 per cent of > you to change a light bulb. > > I have now installed Debian release (wheezy) 64-bit and icedove 31.20 with Enigmail 1.72. > Considering that icedove is Thunderbird and the same version as is Enigmail - I am at a loss > to explain the failings. I just copied folders and files over with no problems. > > David > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users So, does this mean it works now or not ? David, with the deepest respect, you are not very good at providing the correct information you have been asked for, namely detailed steps, detailed failure messages, detailed versions of your packages/distributions. This is going to be my last response to you, if I feel that you are not providing the correct information. Further, just because somebody renames and rebuilds something, does not mean it is THE SAME as the original. The Debian folks might be applying patches, as we do in Fedora and Red Hat/CentOS. That is the thing with free software, just because something sounds or looks similar, does not mean it is! Hence, the requirement for detailed package names and versions and distribution versions. Werner, I know I know! Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at gbenet.com Wed Nov 26 21:53:22 2014 From: david at gbenet.com (david at gbenet.com) Date: Wed, 26 Nov 2014 20:53:22 +0000 Subject: Update In-Reply-To: <54762F9B.4050507@internexusconnect.net> References: <54762BFF.8010409@gbenet.com> <54762F9B.4050507@internexusconnect.net> Message-ID: <54763DC2.3050703@gbenet.com> On 26/11/14 19:52, Tristan Santore wrote: > On 26/11/14 19:37, david at gbenet.com wrote: >> Hi Al, >> >> As so many have been aware, I tried LUbuntu amd64 LXDE with Thunderbird and Enigmail - which >> singularly failed to sign or even encrypt. I made add that Kleopatra Kgpg GPA also failed to >> work. >> >> As some of you are stuck with the mind-set that the earth is flat eg "Oh it works for me >> therefore it works for everyone else" is delusional. As stated I'd not ask 98 per cent of >> you to change a light bulb. >> >> I have now installed Debian release (wheezy) 64-bit and icedove 31.20 with Enigmail 1.72. >> Considering that icedove is Thunderbird and the same version as is Enigmail - I am at a loss >> to explain the failings. I just copied folders and files over with no problems. >> >> David >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > So, does this mean it works now or not ? David, with the deepest respect, you are not very > good at providing the correct information you have been asked for, namely detailed steps, > detailed failure messages, detailed versions of your packages/distributions. This is going > to be my last response to you, if I feel that you are not providing the correct information. > Further, just because somebody renames and rebuilds something, does not mean it is THE SAME > as the original. The Debian folks might be applying patches, as we do in Fedora and Red > Hat/CentOS. That is the thing with free software, just because something sounds or looks > similar, does not mean it is! Hence, the requirement for detailed package names and versions > and distribution versions. > > Werner, I know I know! > > Regards, > Tristan > > -- > > Tristan Santore BSc MBCS > TS4523-RIPE > Network and Infrastructure Operations > InterNexusConnect > Mobile +44-78-55069812 > Tristan.Santore at internexusconnect.net > > Former Thawte Notary > (Please note: Thawte has closed its WoT programme down, > and I am therefore no longer able to accredit trust) > > For Fedora related issues, please email me at: > TSantore at fedoraproject.org > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > Tristan, It all works on Debian - Fedora-16 64-bit well no and LUbuntu LXDE 64-bit no. And it's not LXDE - LUbuntu - is it a kernel issue? Maybe I could never find out. Considering that Kleopatra Kgpg GPA Thunderbird Enigmail ALL Failed - it points to a kernel issue. As happens on this list when people point out that something's not working - those with very limited intelligence start bleating as if we are completely ignorant of what we do. Anyway, I keep away from Fedora - a dodgy system as now I keep well away from LUbuntu 64-bit. Not all Linux Distros work. Not all Linux applications work. This is a fact of life. David -- ?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From tristan.santore at internexusconnect.net Wed Nov 26 21:56:28 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Wed, 26 Nov 2014 20:56:28 +0000 Subject: Update In-Reply-To: <54763DC2.3050703@gbenet.com> References: <54762BFF.8010409@gbenet.com> <54762F9B.4050507@internexusconnect.net> <54763DC2.3050703@gbenet.com> Message-ID: <54763E7C.5050701@internexusconnect.net> On 26/11/14 20:53, david at gbenet.com wrote: > On 26/11/14 19:52, Tristan Santore wrote: >> On 26/11/14 19:37, david at gbenet.com wrote: >>> Hi Al, >>> >>> As so many have been aware, I tried LUbuntu amd64 LXDE with Thunderbird and Enigmail - which >>> singularly failed to sign or even encrypt. I made add that Kleopatra Kgpg GPA also failed to >>> work. >>> >>> As some of you are stuck with the mind-set that the earth is flat eg "Oh it works for me >>> therefore it works for everyone else" is delusional. As stated I'd not ask 98 per cent of >>> you to change a light bulb. >>> >>> I have now installed Debian release (wheezy) 64-bit and icedove 31.20 with Enigmail 1.72. >>> Considering that icedove is Thunderbird and the same version as is Enigmail - I am at a loss >>> to explain the failings. I just copied folders and files over with no problems. >>> >>> David >>> >>> >>> >>> _______________________________________________ >>> Gnupg-users mailing list >>> Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> So, does this mean it works now or not ? David, with the deepest respect, you are not very >> good at providing the correct information you have been asked for, namely detailed steps, >> detailed failure messages, detailed versions of your packages/distributions. This is going >> to be my last response to you, if I feel that you are not providing the correct information. >> Further, just because somebody renames and rebuilds something, does not mean it is THE SAME >> as the original. The Debian folks might be applying patches, as we do in Fedora and Red >> Hat/CentOS. That is the thing with free software, just because something sounds or looks >> similar, does not mean it is! Hence, the requirement for detailed package names and versions >> and distribution versions. >> >> Werner, I know I know! >> >> Regards, >> Tristan >> >> -- >> >> Tristan Santore BSc MBCS >> TS4523-RIPE >> Network and Infrastructure Operations >> InterNexusConnect >> Mobile +44-78-55069812 >> Tristan.Santore at internexusconnect.net >> >> Former Thawte Notary >> (Please note: Thawte has closed its WoT programme down, >> and I am therefore no longer able to accredit trust) >> >> For Fedora related issues, please email me at: >> TSantore at fedoraproject.org >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > Tristan, > > It all works on Debian - Fedora-16 64-bit well no and LUbuntu LXDE 64-bit no. And it's not > LXDE - LUbuntu - is it a kernel issue? Maybe I could never find out. Considering that > Kleopatra Kgpg GPA Thunderbird Enigmail ALL Failed - it points to a kernel issue. > > As happens on this list when people point out that something's not working - those with very > limited intelligence start bleating as if we are completely ignorant of what we do. > > Anyway, I keep away from Fedora - a dodgy system as now I keep well away from LUbuntu > 64-bit. Not all Linux Distros work. Not all Linux applications work. This is a fact of life. > > David > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users Fedora is not dodgy! We only support Fedora for 2 releases + 1 month! Stop using unsupported distributions then. Quite an ignorant statement to make. And that is the last I am writing. Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2014-667rhzu3dc-lists-groups at riseup.net Wed Nov 26 21:58:57 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Wed, 26 Nov 2014 20:58:57 +0000 Subject: can you list just the v3 keys on a GnuPG keyring? Message-ID: <434155755.20141126205857@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Is there a GnuPG command/option combination that will produce a list of just the v3 keys on a GnuPG keyring, or would I have to manipulate the output from something like gpg --with-colons --fingerprint? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Puns are bad but poetry is verse. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlR2Px1XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p8VYEAKeD7ee2W8SOglqFg6ZXcOXAINChmjN3ewBf eoQ1QRty2SH5kt7rgLl/1DLzzIuF6Mrit5Du/qfHXxLyWByY0BEOEdWYttXbVbr3 m9wEKU95lDHlYnJqdvQ1evBLY4zL6bls6sVb6jZ7fURMJYkTvFy+C25gp/vqK7s+ o3V2EJWXiQF8BAEBCgBmBQJUdj8dXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRp b25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZB NUEwRjU2QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw8A8IAL86HcDY7Zid01hb 8lIAkPx12NNjQliyUs+yeMAGbDBIz68kLV5dNSDfXs4yqNxFKacAng7QODi47P3u vdHKBF4ADV77AImDv1yasPnpQLX3CWCB4t6Ge2QAr1Uun3V3qX24MCt24WCEzE/T 3nAhQmchCUF3NLUkPtMnww27XqV3cVvvVKknTUkjBGkU/Lm+6wtPc488Fjjodoo+ Db2oU6cKJtuMf5MUbWd0I5MSu+Ox7QOh6S0k7Nczoc7QedKJByelwNtA0ap5pocO Ups63gEhv5ZjlY8MaV+NXA0PTfe5KJB2Xx47icZBsXxlcgxk822VPVM3NEv1R5ri DGkEwaU= =WZtA -----END PGP SIGNATURE----- From alexanderino at gmail.com Wed Nov 26 22:07:32 2014 From: alexanderino at gmail.com (Jason Antony) Date: Thu, 27 Nov 2014 08:07:32 +1100 Subject: Update In-Reply-To: <54763E7C.5050701@internexusconnect.net> References: <54762BFF.8010409@gbenet.com> <54762F9B.4050507@internexusconnect.net> <54763DC2.3050703@gbenet.com> <54763E7C.5050701@internexusconnect.net> Message-ID: <54764114.6080406@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2014-11-27 07:56, Tristan Santore wrote: > Fedora is not dodgy! We only support Fedora for 2 releases + 1 > month! Stop using unsupported distributions then. Quite an ignorant > statement to make. And that is the last I am writing. More proof that this David @gbenet is almost certainly a troll, with an agenda to make inflammatory, misleading statements that are designed to get a rise out of us, while presenting an almost-plausible case to gain credibility. The best course of action is to ignore him (directed in general to all of us). Cheers, Jason -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUdkENAAoJED1Q2DsLuMaGrNkP/2FE6d0nWAoGpUmtKVZ2MVMe CTO34h6cZIN+TwLbZSo0P6aQquzrVoY8BFXe5Hrn9vBq8QLxQQz8xLMyljjj6wcS YHHYpXpbaFsIcWlxEkOQpRrj9iKSz0qjF59xlztpp4zgTptnbpHyTAu7l3d0JJCc uTT9bC8qOmqwfjU7Csb9FKD6aJXzDhLN/525REqU8YJMbFr4hhDTYzBHtdRSSKeS KIwX+77sYSo+Lxa+q4RJ7JoE29pexIfITVo6wsr/NnkbhUWM2M2AOLGKpQG6vGmh ONhKZIjUeaA6BF3nYi7l6xoE9ziVWq12Y3P60qRNi7p4gj6+Wvb5GFaYsz4Z/9Qz 66Q+5ZChKnIS50pqQqzevQwGp0C8C0l7O2qTvdPRF7vTbJvbUNE3+oV34Ss/UuXv PF+/pS8Po6m1x7+W1ZP/zMBCpAtcNakN9k71V83FP/S+x3RQ+lw+8+f6aiQRclCA K0A7M4zo5266/BoRI2PJ7t2Id/70oDrp8pawLaNw44wfxEkWMSzDoTqZJ1UvTp3a 5zaI3FzFEGcjtNk897gPxFJyyx7VRhaZlz8IC0s7zWvvHZxKF1kVcEnzvpB0SRia ST0rI2niIA1Knlc+99IjP/8DmRLiUap+4ScTT1L1yfisoOkW3dPF+c6s0AEcQcpF fQnjr19XExZ0NJ1rkWns =1yJP -----END PGP SIGNATURE----- From gabriel.niebler at gmail.com Wed Nov 26 23:51:31 2014 From: gabriel.niebler at gmail.com (Gabriel Niebler) Date: Wed, 26 Nov 2014 23:51:31 +0100 Subject: digest-algo SHA256, SHA-1 attacks In-Reply-To: <547626EF.9010103@digitalbrains.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Peter, I just wanted to say thank you very much for the explanation. It was very enlightening. I especially like the fact that, despite nobody asking specifically about SHA-1, you still decided to take the time to write a lengthy message explaining the nature of the known attacks on SHA-1 - and in a very understandable manner, too. I actually learned something today. Kudos gabe -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQFJBAEBCgAzBQJUdllyLBxHYWJyaWVsIE5pZWJsZXIgPGdhYnJpZWwubmllYmxl ckBnbWFpbC5jb20+AAoJEO7XEikU4kSzzvAIAKm0Q/Erhid30Ulx+YrbkXmCgWtC tV94cjZnkaae9U7mJd5UaboHSvEzF7V8fbfUSzf2fVmWZUn6rFsIqdGPEpEHOPMe mgy7e8nyvL0/T+WkY4BIbxwZeX4cpoLa58v4LM+q87l6rCV+6SAB4QmZCJBa5UZ8 ZDdT47hx0/9wn/jtiI6Vfb/1rdSwO2F9rZyAYD2DtCCA9s42UWhf4j164qCMmXxp ihx1o96Xd8J0zWIXRgN9x7AOWND+Ewxn+AzR+REJLomiaK5zE/kHIMm6naGJTuNt boCWfTgOsJMiqdfT8FFHieCmekTsI0kb9gb33fANm8ZzWctQ6W7FOnpQB0o= =KD6Z -----END PGP SIGNATURE----- From mail at robinmathewrajan.com Thu Nov 27 06:52:01 2014 From: mail at robinmathewrajan.com (Robin Mathew Rajan) Date: Thu, 27 Nov 2014 11:22:01 +0530 Subject: Setpref is not working or is it a bug or something? In-Reply-To: References: Message-ID: <5476BC01.9050708@robinmathewrajan.com> Hi gnupgpack, :) You can delete these values from your current gpg.conf. s2k-digest-algo SHA256 s2k-cipher-algo AES256 cert-digest-algo SHA256 digest-algo SHA256 Reason 1: Those values are used when options like 'personal-cipher-preferences', 'personal-digest-preferences' and 'personal-compress-preferences' are not given! But here, you already gave those three options already. Refer: https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html Reason 2: Those values are known to break the OpenPGP standard. OpenPGP is nothing but a set of guidelines which instructs on how the PGP concept should be implemented in various softwares. Let's quote an example to get the idea of 'IETF standards' effectively. We all know how a Desktop Computer looks like. Mouse, Keyboard, LCD Monitor, A case in which the CPU, Motherboard, HDDs are included and a unique OS etc. That's what a typical desktop computer look like. We can call that 'typical' desktop computer to be 'reference model.' Or in another words, that computer could be a 'standard computer'. Now let's have a look at another Desktop Computer. Based on the earlier reference model of Desktop Computer, another one built a Desktop Computer. This computer has all the features of earlier reference model, plus, the features of its own. This one includes: bigger case with lots of fancy lights, liquid cooling systems, SSDs, GPGPUs, OS with more features etc. None of these extra features are not in the earlier reference computer. Both are Desktop Computers. But what's the difference? The former is a reference computer with all the essentials built-in which respects compatibility. The latter one is a high-end one which includes fancy options but not compulsory to be in a computer. And moreover, since the OS second computer holds more features than the reference model, when connected to a network, the both computers can't communicate. To communicate, both computers should know a common language with common instructions. If the communication language is different, there will be no communication. It's just like we humans use 'English' as a common language. We all come from different nations. We all have different languages. But there should be something in common to communicate. Moreover, surprisingly, the English language itself has different accents around the world. I'm an Indian. We use Indian accented English. So does people from other parts of the world. But since the accents of English language is fragmented, there should have one reference accent which all other people from all nations should consider learning. And that's the native accents 'British' or 'American' accents mainly. That's the same OpenPGP does. OpenPGP standard is just a reference model. Anyone can modify it and include unique features. But it's not necessary to be those 'unique features' to be included in every OpenPGP implemented products. But when it comes to communicating each other, there comes the problem if there's no common standard rule. With those settings, the communication between Symantec owned PGP products and GnuPG will be problematic. That's why we have to stick to the reference standards as much as possible. But there's a caveat with strict implementation of standards. In cryptography, there's a Performance vs Security thing. If we tend to move more towards Performance, the Security will be low. And if we tend to move more towards Security, the Performance will be low. We have to maintain the level of Security vs Performance trade-off, to be medium as possible. As because there are so many OpenPGP implementations, we can't really guarantee which configuration is more compatible and which configuration is most secure. If we tend to move more towards compatibility, the level of security will be low. And we tend to move more towards security, compatibility will be an issue. That's why I chose, these four extra configurations which I believe most secure with fewer compatibility issues with newer releases of OpenPGP implementations and other softwares. These preferences won't break the OpenPGP implementation, but at the same time, offers high security too. default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 CAMELLIA128 AES CAST5 IDEA BZIP2 ZLIB ZIP personal-cipher-preferences AES256 CAMELLIA256 TWOFISH personal-digest-preferences SHA512 personal-compress-preferences BZIP2 But at the same time, these settings might be incompatible with older softwares. But that's something we should decide personally. Should we choose the most compatible configuration or the most secure configuration? Let's that decide ourselves. Refer: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html Reason 3: You have set 's2k-digest-algo', 'cert-digest-algo' and 'digest-algo' configurations to SHA-256. But at the same time, you have set 'personal-digest-preferences' and 'default-preference-list' configurations to SHA-512. That's incompatible and contradictory configuration. Our, Robert J. Hansen already said that in another thread in 2012. "Robert J. Hansen | 27 May 13:29 2012 Re: A mixed case of keys and AES256 vs CAST5 > In my gpg.conf file, I have the following settings: > > cipher-algo aes256 Please don't do this. This overrides GnuPG's built-in algorithm selector. The algorithm selector makes sure that your traffic will be readable by your recipient's OpenPGP implementation. There exist a lot of OpenPGP implementations (particularly PGP 7.0 and prior) that don't support AES256. This option will make your data unreadable by those systems. It is enough to have AES256 listed as your most-preferred cipher. > personal-digest-preferences SHA256 > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > CAST5 ZLIB BZIP2 ZIP Uncompressed These two lines contradict each other. First you say SHA256 is your preferred digest, then you say SHA512 is. I don't have an answer for why you're seeing two different algorithms being used, I'm sorry. I have a few guesses, but no certainties. > A message will be sent to an organisation and the sender does not want to > encrypt it with her own key, ergo mail address. However, she wants to have > possible access to the content in the future. This is what the "hidden-encrypt-to" option is meant for. You don't need symmetric encryption." Refer: http://comments.gmane.org/gmane.comp.security.pgp-basics/7339 Additionally, by typing this command, we can see how our existing keys are encrypted. For Linux: gpg --list-packets ~/.gnupg/secring.gpg For Windows: %APPDATA%\gnupg\secring.gpg For example, C:\Users\Admin\AppData\Roaming\gnupg\secring.gpg Replace 'Admin' with your user name. So it becomes, C:\Users\\AppData\Roaming\gnupg\secring.gpg Thanks and regards, :) Robin Mathew Rajan https://www.robinmathewrajan.com/ On 26-11-2014 PM 04:44, gnupgpack at on.yourweb.de wrote: > Hello, > >> No. The 2.0 cards from ZeitControl all support 4096 (if you feel a need >> for this). The problem was that old GnupG versions limited them to 3k. > > I am working with GnuPG-Pack, which includes extended gpg-1.4.18. > This versions supports smartcard keys with 4096bit? > >>> So, what are the most useful cross-over compatibility settings for new, >>> secure keys? >> Use the defaults and ignore the suggestions you find out in the wild. > > What's about the standard SHA1 hash with signatures? > In gpg.conf really no need for: > > s2k-count 1000000 > s2k-digest-algo SHA256 > s2k-cipher-algo AES256 > cert-digest-algo SHA256 > digest-algo SHA256 > personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 > personal-compress-preferences ZLIB BZIP2 ZIP > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 TWOFISH AES192 > AES CAST5 ZLIB BZIP2 ZIP > > ??? > > Thanks a lot, regards @g. > > *still learning...* > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From ndk.clanbo at gmail.com Thu Nov 27 06:55:34 2014 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 27 Nov 2014 06:55:34 +0100 Subject: digest-algo SHA256, SHA-1 attacks In-Reply-To: <54762C75.6080607@digitalbrains.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> <54762C75.6080607@digitalbrains.com> Message-ID: <5476BCD6.2010007@gmail.com> Il 26/11/2014 20:39, Peter Lebbing ha scritto: > On 26/11/14 20:31, NdK wrote: >> Well, IIUC with rhash you're giving the attacker another mean to tamper >> with your message. Unless 'r' is chosen deterministically. > 'r' is randomly generated for each signature by the /signing/ party. So the > attacker loses control over the input to the hashing algorithm, and they no > longer can use collision attacks because they don't know the exact input to the > hashing algorithm. Sorry, I've been too concise. I see two problems with randomizing crypto: 1) who guarantees that the 'r' seen by the receiving party is the same generated by the signer? Since it's usually trivially combined with source text, I feel it's a huge attack vector 2) it could be a side-channel for leakage (say a smartcard under some control by some TLA that encrypts the used secret key and some really random bytes and uses the result as 'r') BYtE, Diego. From mail at robinmathewrajan.com Thu Nov 27 08:39:08 2014 From: mail at robinmathewrajan.com (Robin Mathew Rajan) Date: Thu, 27 Nov 2014 13:09:08 +0530 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <5476BC01.9050708@robinmathewrajan.com> References: <5476BC01.9050708@robinmathewrajan.com> Message-ID: <5476D51C.6070201@robinmathewrajan.com> Hi gnupgpack, :) You can delete these values from your current gpg.conf. s2k-digest-algo SHA256 s2k-cipher-algo AES256 cert-digest-algo SHA256 digest-algo SHA256 Reason 1: Those values are used when options like 'personal-cipher-preferences', 'personal-digest-preferences' and 'personal-compress-preferences' are not given! But here, you already gave those three options already. Refer: https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html Reason 2: Those values are known to break the OpenPGP standard. OpenPGP is nothing but a set of guidelines which instructs on how the PGP concept should be implemented in various softwares. Let's quote an example to get the idea of 'IETF standards' effectively. We all know how a Desktop Computer looks like. Mouse, Keyboard, LCD Monitor, A case in which the CPU, Motherboard, HDDs are included and a unique OS etc. That's what a typical desktop computer look like. We can call that 'typical' desktop computer to be 'reference model.' Or in another words, that computer could be a 'standard computer'. Now let's have a look at another Desktop Computer. Based on the earlier reference model of Desktop Computer, another one built a Desktop Computer. This computer has all the features of earlier reference model, plus, the features of its own. This one includes: bigger case with lots of fancy lights, liquid cooling systems, SSDs, GPGPUs, OS with more features etc. None of these extra features are not in the earlier reference computer. Both are Desktop Computers. But what's the difference? The former is a reference computer with all the essentials built-in which respects compatibility. The latter one is a high-end one which includes fancy options but not compulsory to be in a computer. And moreover, since the OS second computer holds more features than the reference model, when connected to a network, the both computers can't communicate. To communicate, both computers should know a common language with common instructions. If the communication language is different, there will be no communication. It's just like we humans use 'English' as a common language. We all come from different nations. We all have different languages. But there should be something in common to communicate. Moreover, surprisingly, the English language itself has different accents around the world. I'm an Indian. We use Indian accented English. So does people from other parts of the world. But since the accents of English language is fragmented, there should have one reference accent which all other people from all nations should consider learning. And that's the native accents 'British' or 'American' accents mainly. That's the same OpenPGP does. OpenPGP standard is just a reference model. Anyone can modify it and include unique features. But it's not necessary to be those 'unique features' to be included in every OpenPGP implemented products. But when it comes to communicating each other, there comes the problem if there's no common standard rule. With those settings, the communication between Symantec owned PGP products and GnuPG will be problematic. That's why we have to stick to the reference standards as much as possible. But there's a caveat with strict implementation of standards. In cryptography, there's a Performance vs Security thing. If we tend to move more towards Performance, the Security will be low. And if we tend to move more towards Security, the Performance will be low. We have to maintain the level of Security vs Performance trade-off, to be medium as possible. As because there are so many OpenPGP implementations, we can't really guarantee which configuration is more compatible and which configuration is most secure. If we tend to move more towards compatibility, the level of security will be low. And we tend to move more towards security, compatibility will be an issue. That's why I chose, these four extra configurations which I believe most secure with fewer compatibility issues with newer releases of OpenPGP implementations and other softwares. These preferences won't break the OpenPGP implementation, but at the same time, offers high security too. default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 TWOFISH AES192 CAMELLIA192 CAMELLIA128 AES CAST5 IDEA BZIP2 ZLIB ZIP personal-cipher-preferences AES256 CAMELLIA256 TWOFISH personal-digest-preferences SHA512 personal-compress-preferences BZIP2 But at the same time, these settings might be incompatible with older softwares. But that's something we should decide personally. Should we choose the most compatible configuration or the most secure configuration? Let's that decide ourselves. Refer: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html Reason 3: You have set 's2k-digest-algo', 'cert-digest-algo' and 'digest-algo' configurations to SHA-256. But at the same time, you have set 'personal-digest-preferences' and 'default-preference-list' configurations to SHA-512. That's incompatible and contradictory configuration. Our, Robert J. Hansen already said that in another thread in 2012. "Robert J. Hansen | 27 May 13:29 2012 Re: A mixed case of keys and AES256 vs CAST5 > In my gpg.conf file, I have the following settings: > > cipher-algo aes256 Please don't do this. This overrides GnuPG's built-in algorithm selector. The algorithm selector makes sure that your traffic will be readable by your recipient's OpenPGP implementation. There exist a lot of OpenPGP implementations (particularly PGP 7.0 and prior) that don't support AES256. This option will make your data unreadable by those systems. It is enough to have AES256 listed as your most-preferred cipher. > personal-digest-preferences SHA256 > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES > CAST5 ZLIB BZIP2 ZIP Uncompressed These two lines contradict each other. First you say SHA256 is your preferred digest, then you say SHA512 is. I don't have an answer for why you're seeing two different algorithms being used, I'm sorry. I have a few guesses, but no certainties. > A message will be sent to an organisation and the sender does not want to > encrypt it with her own key, ergo mail address. However, she wants to have > possible access to the content in the future. This is what the "hidden-encrypt-to" option is meant for. You don't need symmetric encryption." Refer: http://comments.gmane.org/gmane.comp.security.pgp-basics/7339 Additionally, by typing this command, we can see how our existing keys are encrypted. For Linux: gpg --list-packets ~/.gnupg/secring.gpg For Windows: %APPDATA%\gnupg\secring.gpg For example, C:\Users\Admin\AppData\Roaming\gnupg\secring.gpg Replace 'Admin' with your user name. So it becomes, C:\Users\\AppData\Roaming\gnupg\secring.gpg Thanks and regards, :) Robin Mathew Rajan https://www.robinmathewrajan.com/ > What's about the standard SHA1 hash with signatures? > In gpg.conf really no need for: > > s2k-count 1000000 > s2k-digest-algo SHA256 > s2k-cipher-algo AES256 > cert-digest-algo SHA256 > digest-algo SHA256 > personal-cipher-preferences AES256 TWOFISH AES192 AES CAST5 > personal-digest-preferences SHA512 SHA384 SHA256 SHA224 > personal-compress-preferences ZLIB BZIP2 ZIP > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 TWOFISH AES192 > AES CAST5 ZLIB BZIP2 ZIP > > ??? > > Thanks a lot, regards @g. > > *still learning...* From bernhard at intevation.de Thu Nov 27 09:20:29 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 27 Nov 2014 09:20:29 +0100 Subject: Funding for GpgOL (Gpg4win/GnuPG)? In-Reply-To: <20141124090351.5e0ec147@scorpio> References: <201411241001.38899.bernhard@intevation.de> <87ppcceo8f.fsf@vigenere.g10code.de> <20141124090351.5e0ec147@scorpio> Message-ID: <201411270920.34921.bernhard@intevation.de> On Monday 24 November 2014 at 15:03:51, Jerry wrote: > On Mon, 24 Nov 2014 14:12:48 +0100, Werner Koch stated: > > To be fair, that changed with Outlook 2010. ?We merely had not the > > resources to change GpgOL to make use of the new Outlook structure. > > Interesting; has there been any movement on that front? I use Outlook 2013 > at my office and that would be a handy feature to have. This would be best asked on https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-users-en The answer is: no - the situation is similiar to earlier reports. GnuPG and Gpg4win development needs serious funding to be able to larger necessary steps like an overhaul of the user interface or an PGP/MIME GpgOL. There are some ideas to try to get some funding for GnuPG, which Werner can best report on. He improved his system for volunteer payment (some call it donations) for instance. In Germany there were some political statements aming to support funding GnuPG or Gpg4win, but no tangible plans that g10code or Intevation have been approached with. Right now our best and most reliable source of funding is single "donations". Though they can only support Gpg4win/GnuPG development on a very low level, we are very grateful for each single one. Thanks! Best, Bernhard ps.: Flattr Gpg4win at https://flattr.com/thing/2053326, if you appreciate this answer and my work as part of the Gpg4win team. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Nov 27 09:23:51 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 27 Nov 2014 09:23:51 +0100 Subject: Pros and cons of PGP/MIME for outgoing e-mail? In-Reply-To: <54744E4F.30506@fifthhorseman.net> References: <201411241001.38899.bernhard@intevation.de> <201411250942.17695.bernhard@intevation.de> <54744E4F.30506@fifthhorseman.net> Message-ID: <201411270923.52929.bernhard@intevation.de> On Tuesday 25 November 2014 at 10:39:27, Daniel Kahn Gillmor wrote: > This is supposed to be http://bugs.python.org/issue1670765, which is > claimed to be resolved. Thanks for the link, I did not look into this for a few years. > If it's not resolved, someone needs to let the python devs know about it. As written there, like in my original report from this one, there still will be issues with spaces in header lines and probably some other stuff they reformat. Yes, someone would be needed to fully test all this. It would be very useful if someone like Bjarni or somebody elseo would test and report this with Python. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Thu Nov 27 11:07:03 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 27 Nov 2014 11:07:03 +0100 Subject: digest-algo SHA256, SHA-1 attacks In-Reply-To: <5476BCD6.2010007@gmail.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> <54762C75.6080607@digitalbrains.com> <5476BCD6.2010007@gmail.com> Message-ID: <5476F7C7.2070209@digitalbrains.com> On 27/11/14 06:55, NdK wrote: > 1) who guarantees that the 'r' seen by the receiving party is the same > generated by the signer? Since it's usually trivially combined with > source text, I feel it's a huge attack vector The purpose of the signature is to ascertain that the OpenPGP message has not been modified in transit. If you flip a byte anywhere in the message, either in 'r', or in the actual message, the hash changes. This is all the effect it has: the hash changes; there is no remote code execution or anything :). And since the hash changes, the message fails to verify as a valid signature. Are you thinking of a preimage attack where the attacker is now able to vary the hash of their nefarious message by varying 'r'? If there's a preimage attack against the hash function, you've lost. Randomized hash or not, it's bye-bye. I must admit I haven't read the actual specifications and publications surrounding randomized hashing. But perhaps you should read them if you're worried; they might answer your questions? > 2) it could be a side-channel for leakage (say a smartcard under some > control by some TLA that encrypts the used secret key and some really > random bytes and uses the result as 'r') First of all, in the case of an OpenPGP card, the smartcard never sees or comes in contact with 'r'. It just signs the hash using its private key. I'd assume this is a common setup for smartcards doing crypto, since you wouldn't want to feed your multi-gigabyte signed datafile through a smartcard interface. That would take ages. I'm fairly sure this side channel does not exist in the current OpenPGP card as long as you don't use the on-card key generation. And adding randomized hashing would not change that situation. And it doesn't make sense when the PC signing your message is the one that is leaking information through 'r'... If "They"[1] control your PC, it's game over. Could you get a little more concrete than "I feel it's a huge attack vector"? It's kind of difficult to argue with, second guessing and all. HTH, Peter. [1] I feel "They" should be a 3 letter word, to fit with the parties it usually refers to. Then again, 4 letter words have a nice reputation as well. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Thu Nov 27 11:28:18 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 27 Nov 2014 11:28:18 +0100 Subject: Randomized hashing (was: digest-algo SHA256, SHA-1 attacks) In-Reply-To: <5476F7C7.2070209@digitalbrains.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> <54762C75.6080607@digitalbrains.com> <5476BCD6.2010007@gmail.com> <5476F7C7.2070209@digitalbrains.com> Message-ID: <5476FCC2.70701@digitalbrains.com> Perhaps I should add that it takes real research and formal proof to show that this randomized hashing doesn't add attack vectors, and I have been glossing over that. But that is because at a glance it looks like such research has been done. That doesn't mean it's a fact that there are no significant attack vectors, but it does give the scheme credibility. Here's the abstract of the first paper on [1], by the way: > We propose randomized hashing as a mode of operation for cryptographic hash > functions intended for use with standard digital signatures and without > necessitating of any changes in the internals of the underlying hash function > (e.g., the SHA family) or in the signature algorithms (e.g., RSA or DSA). The > goal is to free practical digital signature schemes from their current > reliance on strong collision resistance by basing the security of these > schemes on significantly weaker properties of the underlying hash function, > thus providing a safety net in case the (current or future) hash functions in > use turn out to be less resilient to collision search than initially > thought. We design a specific mode of operation that takes into account > engineering considerations (such as simplicity, efficiency and compatibility > with existing implementations) as well as an- alytical soundness. > Specifically, the scheme entails unmodified use of the hash function with > randomization applied only to the message before it is input to the hash > function. We formally show the sufficiency of an assumption significantly > weaker than collision-resistance for proving the security of the scheme. We > also contribute to the standardization of a randomized hashing mode by > providing a full and detailed spec that instantiates our scheme, provides the > full benefits guaranteed by our results, and is ready for implementation and > integration with existing applications. Peter. [1] http://webee.technion.ac.il/~hugo/rhash/ -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From bernhard at intevation.de Thu Nov 27 11:57:24 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 27 Nov 2014 11:57:24 +0100 Subject: Gpg4win 2.2.3 released with GnuPG Message-ID: <201411271157.30511.bernhard@intevation.de> You seen the news Gpg4win 2.2.3 is here. :) http://lists.wald.intevation.org/pipermail/gpg4win-announce/2014-November/000062.html and with 2.0.26. So why not GnuPG 2.1? Because 2.2.3 is a minor release that fixes important defects. Before we can publish a GnuPG version with GnuPG 2.1 we would need to invest a lot more time in testing. This would have delayed the release further. On the other hand, Werner publishes an "experimental" windows installer for 2.1, so you can help with testing. :) Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Nov 27 12:05:18 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 27 Nov 2014 12:05:18 +0100 Subject: Security patches and gpg 1/2 development In-Reply-To: <54762327.4000008@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 26 Nov 2014 13:59:51 -0500") References: <54762327.4000008@fifthhorseman.net> Message-ID: <87oars3nv5.fsf@vigenere.g10code.de> On Wed, 26 Nov 2014 19:59, dkg at fifthhorseman.net said: > Hopefully Werner can weigh in on what to do if you have a sensitive > security issue that you want to embargo (this should probably also be > added somewhere prominent on https://www.gnupg.org/) $ head -7 AUTHORS Program: GnuPG Homepage: https://www.gnupg.org Download: ftp://ftp.gnupg.org/gcrypt/gnupg/ Repository: git://git.gnupg.org/gnupg.git Maintainer: Werner Koch Bug reports: http://bugs.gnupg.org Security related bug reports: Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From leonid.isaev at jila.colorado.edu Thu Nov 27 00:19:11 2014 From: leonid.isaev at jila.colorado.edu (Leonid Isaev) Date: Wed, 26 Nov 2014 16:19:11 -0700 Subject: Receiving keys as root user In-Reply-To: <546AC097.4040608@archlinux.org> References: <546A17E6.5040302@archlinux.org> <546A692C.3010504@fifthhorseman.net> <546A8008.7010604@archlinux.org> <546AC097.4040608@archlinux.org> Message-ID: <20141126231911.GA5309@takahe.colorado.edu> Hi, On Tue, Nov 18, 2014 at 01:44:23PM +1000, Allan McRae wrote: > I have found running "dirmngr < /dev/null" as root creates > /root/.gnupg/S.dirmngr and allows gpg to work properly. > > Is this something that should happen automatically? > I think this is a bug in gpg because /root/.gnupg should be irrelevant for the pacman keyring in /etc/pacman.d/gnupg (and I also think that the 'fix' in archlinux is wrong since the root user doesn't need to have a .gnupg dir). Confusingly, it seems [1] that dirmngr should be working though... [1] http://lists.gnupg.org/pipermail/gnupg-devel/2014-April/028427.html Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D From peter at digitalbrains.com Thu Nov 27 14:45:31 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 27 Nov 2014 14:45:31 +0100 Subject: Randomized hashing In-Reply-To: <54771347.5080609@gmail.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> <54762C75.6080607@digitalbrains.com> <5476BCD6.2010007@gmail.com> <5476F7C7.2070209@digitalbrains.com> <5476FCC2.70701@digitalbrains.com> <54771347.5080609@gmail.com> Message-ID: <54772AFB.4050806@digitalbrains.com> On 27/11/14 13:04, NdK wrote: > (note that r is not signed, as the rhash scheme suggests and the paper > confirms!) > "In contrast to a previous proposal by the same authors, the salt r does not > need to be included under the signature." I read this quite differently. I read it as that 'r' is not included in the signature, that is, what is signed is still just the hash. It seems profoundly silly to not include it in the signed data, for the reasons you mention. Can you give a quote that actually says 'r' is not included in the signed data? > At a first glance, it would be safer to have r *inside* the signature. Oh, I agree, I already thought that might close any 'r'-swapping security issues, if there would be any; just like you can include the hash algorithm in the signature to prevent swapping it out for a weaker one. But when swapping 'r''s does not actually create any security issues, it just makes things needlessly complicated. To use your smartcard example: the smartcard only accepts a specifically formatted message. If you change that message to now include a new value, you would need a new smartcard. Furthermore, the size of 'r' might pose a problem; it's a significant addition to the data structure that is signed. > Maybe it's just a performance issue? I suppose also simplicity, verifiability, implementation cost... The rest seems unrelated to randomized hashing except for what I already mentioned: that including 'r' in the signature would mean you can't use an existing OpenPGP card. But I'll answer anyway. > And IMVHO it's better if the padding is generated by the card, depending on > the operation being performed For RSA signatures, the padding is constant; there's nothing to generate. For RSA decryption, the input is generated by the encrypting party; there's nothing to generate on decryption. > while the op is anyway 'RSA encrypt', the padding should be different if > you're signing an hash or exchanging a session key. Failing to let the card > do the padding could lead to exposure of the private key, IIRC. I think you mean "RSA decrypt", for signing you use the "RSA decrypt" primitive, just as you use to decrypt a session key. But this is all already done in the OpenPGP card. It checks the data to be signed conforms to PKCS#1; it is optional to check the DigestInfo, but the rest of the data structure already differentiates it from an encrypted session key. It will only let you sign with the "Signing" and "Authentication" keys. Likewise, it checks that the output of decrypting with the "Decryption" key conforms to the PKCS#1 format, so you can't fool it into a signing operation either. Failing to let the card check the padding could lead to major issues. But this is a solved problem and unrelated to randomized hashing. I don't understand the relevance. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From ndk.clanbo at gmail.com Thu Nov 27 17:10:08 2014 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 27 Nov 2014 17:10:08 +0100 Subject: Randomized hashing In-Reply-To: <5476FCC2.70701@digitalbrains.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> <54762C75.6080607@digitalbrains.com> <5476BCD6.2010007@gmail.com> <5476F7C7.2070209@digitalbrains.com> <5476FCC2.70701@digitalbrains.com> Message-ID: <54774CE0.5020703@gmail.com> Il 27/11/2014 11:28, Peter Lebbing ha scritto: [Resending to list] > Perhaps I should add that it takes real research and formal proof to show that > this randomized hashing doesn't add attack vectors, and I have been glossing > over that. But that is because at a glance it looks like such research has been > done. That doesn't mean it's a fact that there are no significant attack > vectors, but it does give the scheme credibility. Well, I'm no expert, but it gives me the feeling of being potentially dangerous, since once the attacker have your signature for a document s=E(Prk, H(RMX(M,r))) , r (note that r is not signed, as the rhash scheme suggests and the paper confirms!) he *might* be able to calculate r' so that RMX(M',r') == RMX(M,r) then 'recycle' your signature for M'. Remember that RMX is proposed to be a simple block-xor! For very short (less than a single hash block) messages it's trivial, if I'm not badly mislead by the graphic description in the site: RMX(0, 1) == RMX(1, 0) Citing from the paper: "RMX can be used with any hash-then-sign scheme by replacing the digest H(m) in the original signature scheme with H(RM X(r, m)). In this case, the salt r is generated for each signature by the signer and transmitted to the verifier together with the message and signature[1]" and the footnote [1] is "In contrast to a previous proposal by the same authors, the salt r does not need to be included under the signature." . I haven't yet found out why he changed his mind. At a first glance, it would be safer to have r *inside* the signature. This way the attacker couldn't change it. But maybe that exposes other problems. To me it appears that *any* encryption of the message before hashing would lead to analogue security properties. Say you generate 'r' and use it as 'session key' to block-encrypt M then sign the hash of encrypted M (IMVHO it's better if the signature includes r too). Maybe it's just a performance issue? BTW, some smartcards want you to feed 'em the hash state and the last block of data so they can calculate the last hashing step by themselves. And IMVHO it's better if the padding is generated by the card, depending on the operation being performed: while the op is anyway 'RSA encrypt', the padding should be different if you're signing an hash or exchanging a session key. Failing to let the card do the padding could lead to exposure of the private key, IIRC. BYtE, Diego. From aixtools at gmail.com Thu Nov 27 18:40:15 2014 From: aixtools at gmail.com (Michael Felt) Date: Thu, 27 Nov 2014 18:40:15 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: <87d28cg6k1.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87d28cg6k1.fsf@vigenere.g10code.de> Message-ID: I decided to be a bit more pragmatic, and just packaged and loaded libiconv-1.14. Now configure completes, but make fails (with xlC or vac) on: + /opt/bin/make > build/aix/make.out "http.c", line 1931.1: 1506-343 (S) Redeclaration of parse_response differs from previous declaration on line 181 of "http.c". "http.c", line 1931.1: 1506-050 (I) Return type "enum {...}" in redeclaration is not compatible with the previous return type "unsigned int". make[3]: *** [libcommontls_a-http.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 /opt/bin/make returned an error There may be more messages (to come), but this is where it stops for now. Michael p.s. My last note was only to the list. Did it show up? (I shall go register - now while I think of it!) On Mon, Nov 24, 2014 at 12:51 PM, Werner Koch wrote: > On Sat, 22 Nov 2014 16:30, aixtools at gmail.com said: > > > However, configure is reporting - in config.log that AIX does not have > > libiconv - which it does. So, my question is: to which gnu tool should I > > Well, the code does not detect it or it is not usable. The latter > should be reported. > > The detection code is source copied in GnuPG and used to create the > configure script. Some parts have not been updated for a long time and > thus it might help to update them. Can you send me the complete > config.log by private mail? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aixtools at gmail.com Thu Nov 27 18:57:28 2014 From: aixtools at gmail.com (Michael Felt) Date: Thu, 27 Nov 2014 18:57:28 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: References: <87ioisn1mo.fsf@vigenere.g10code.de> <87d28cg6k1.fsf@vigenere.g10code.de> Message-ID: So, being even more pragmatic - I have loaded a system with gcc - I get a package, about to run "make check". Below is a list of the messages coming to stderr from gcc-4.7.4 root at x065:[/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0]buildaix --with-libiconv-prefix=/opt gcc is /opt/bin/gcc + CPPFLAGS="-I/opt/include" CFLAGS="-I/opt/aixtools/include -O2" ./configure \ --prefix=/opt \ --sysconfdir=/var/gnupg/etc \ --sharedstatedir=/var/gnupg/com \ --localstatedir=/var/gnupg \ --mandir=/usr/share/man \ --infodir=/opt/share/info/gnupg --with-libiconv-prefix=/opt \ > build/aix/configure.out configure: WARNING: *** *** Building without NTBTLS and GNUTLS - no TLS access to keyservers. *** *** configure: WARNING: *** *** Building without LDAP support. *** No CRL access or X.509 certificate search available. *** configure: WARNING: zlib.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: zlib.h: proceeding with the compiler's result + /opt/bin/make > build/aix/make.out stringhelp.c: In function 'print_sanitized_buffer2': stringhelp.c:692:11: warning: value computed is not used [-Wunused-value] stringhelp.c:696:15: warning: value computed is not used [-Wunused-value] stringhelp.c:701:15: warning: value computed is not used [-Wunused-value] stringhelp.c:706:15: warning: value computed is not used [-Wunused-value] stringhelp.c:711:15: warning: value computed is not used [-Wunused-value] stringhelp.c:716:15: warning: value computed is not used [-Wunused-value] stringhelp.c:721:15: warning: value computed is not used [-Wunused-value] stringhelp.c:732:11: warning: value computed is not used [-Wunused-value] argparse.c: In function 'ignore_invalid_option_add': argparse.c:360:11: warning: value computed is not used [-Wunused-value] argparse.c: In function 'optfile_parse': argparse.c:476:11: warning: value computed is not used [-Wunused-value] mischelp.c: In function 'timegm': mischelp.c:197:5: warning: implicit declaration of function 'gnupg_unsetenv' [-Wimplicit-function-declaration] b64enc.c: In function 'b64enc_write': b64enc.c:282:17: warning: value computed is not used [-Wunused-value] b64enc.c: In function 'b64enc_finish': b64enc.c:358:13: warning: value computed is not used [-Wunused-value] b64enc.c:400:13: warning: value computed is not used [-Wunused-value] miscellaneous.c: In function 'print_hexstring': miscellaneous.c:218:7: warning: value computed is not used [-Wunused-value] miscellaneous.c:219:7: warning: value computed is not used [-Wunused-value] xreadline.c: In function 'read_line': xreadline.c:86:16: warning: value computed is not used [-Wunused-value] xreadline.c:93:38: warning: value computed is not used [-Wunused-value] ttyio.c: In function 'tty_print_string': ttyio.c:386:17: warning: value computed is not used [-Wunused-value] ttyio.c:388:19: warning: value computed is not used [-Wunused-value] ttyio.c:390:19: warning: value computed is not used [-Wunused-value] ttyio.c:395:15: warning: value computed is not used [-Wunused-value] ttyio.c: In function 'tty_kill_prompt': ttyio.c:686:2: warning: value computed is not used [-Wunused-value] ttyio.c:688:6: warning: value computed is not used [-Wunused-value] ttyio.c:689:2: warning: value computed is not used [-Wunused-value] helpfile.c: In function 'findkey_fname': helpfile.c:69:22: warning: value computed is not used [-Wunused-value] stringhelp.c: In function 'print_sanitized_buffer2': stringhelp.c:692:11: warning: value computed is not used [-Wunused-value] stringhelp.c:696:15: warning: value computed is not used [-Wunused-value] stringhelp.c:701:15: warning: value computed is not used [-Wunused-value] stringhelp.c:706:15: warning: value computed is not used [-Wunused-value] stringhelp.c:711:15: warning: value computed is not used [-Wunused-value] stringhelp.c:716:15: warning: value computed is not used [-Wunused-value] stringhelp.c:721:15: warning: value computed is not used [-Wunused-value] stringhelp.c:732:11: warning: value computed is not used [-Wunused-value] argparse.c: In function 'ignore_invalid_option_add': argparse.c:360:11: warning: value computed is not used [-Wunused-value] argparse.c: In function 'optfile_parse': argparse.c:476:11: warning: value computed is not used [-Wunused-value] mischelp.c: In function 'timegm': mischelp.c:197:5: warning: implicit declaration of function 'gnupg_unsetenv' [-Wimplicit-function-declaration] b64enc.c: In function 'b64enc_write': b64enc.c:282:17: warning: value computed is not used [-Wunused-value] b64enc.c: In function 'b64enc_finish': b64enc.c:358:13: warning: value computed is not used [-Wunused-value] b64enc.c:400:13: warning: value computed is not used [-Wunused-value] miscellaneous.c: In function 'print_hexstring': miscellaneous.c:218:7: warning: value computed is not used [-Wunused-value] miscellaneous.c:219:7: warning: value computed is not used [-Wunused-value] xreadline.c: In function 'read_line': xreadline.c:86:16: warning: value computed is not used [-Wunused-value] xreadline.c:93:38: warning: value computed is not used [-Wunused-value] ttyio.c: In function 'tty_print_string': ttyio.c:386:17: warning: value computed is not used [-Wunused-value] ttyio.c:388:19: warning: value computed is not used [-Wunused-value] ttyio.c:390:19: warning: value computed is not used [-Wunused-value] ttyio.c:395:15: warning: value computed is not used [-Wunused-value] ttyio.c: In function 'tty_kill_prompt': ttyio.c:686:2: warning: value computed is not used [-Wunused-value] ttyio.c:688:6: warning: value computed is not used [-Wunused-value] ttyio.c:689:2: warning: value computed is not used [-Wunused-value] helpfile.c: In function 'findkey_fname': helpfile.c:69:22: warning: value computed is not used [-Wunused-value] t-stringhelp.c: In function 'test_strconcat': t-stringhelp.c:201:20: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:210:20: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:220:20: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:231:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:234:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:239:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:244:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:248:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:253:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:257:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:262:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:267:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c: In function 'test_xstrconcat': t-stringhelp.c:282:20: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:291:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:294:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:299:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:304:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:308:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:313:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:317:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:322:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:327:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c: In function 'test_make_filename_try': t-stringhelp.c:344:28: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:353:28: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:363:28: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:372:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:377:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:382:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:387:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:392:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:398:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:417:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c: In function 'test_make_absfilename_try': t-stringhelp.c:445:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:456:3: warning: missing sentinel in function call [-Wformat] t-stringhelp.c:467:3: warning: missing sentinel in function call [-Wformat] t-session-env.c: In function 'show_stdnames': t-session-env.c:66:3: warning: value computed is not used [-Wunused-value] t-dns-cert.c: In function 'main': t-dns-cert.c:78:4: warning: value computed is not used [-Wunused-value] t-exechelp.c: In function 'print_open_fds': t-exechelp.c:43:7: warning: value computed is not used [-Wunused-value] t-exechelp.c:44:7: warning: value computed is not used [-Wunused-value] t-exechelp.c:45:7: warning: value computed is not used [-Wunused-value] t-exechelp.c:48:7: warning: value computed is not used [-Wunused-value] t-exechelp.c:50:3: warning: value computed is not used [-Wunused-value] keybox-file.c: In function '_keybox_read_blob2': keybox-file.c:67:13: warning: value computed is not used [-Wunused-value] keybox-file.c:68:16: warning: value computed is not used [-Wunused-value] keybox-file.c:69:16: warning: value computed is not used [-Wunused-value] keybox-file.c:70:16: warning: value computed is not used [-Wunused-value] keybox-file.c:71:18: warning: value computed is not used [-Wunused-value] keybox-update.c: In function 'keybox_delete': keybox-update.c:643:12: warning: value computed is not used [-Wunused-value] keybox-dump.c: In function 'print_string': keybox-dump.c:60:11: warning: value computed is not used [-Wunused-value] keybox-dump.c:62:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:64:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:66:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:68:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:70:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:72:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:77:9: warning: value computed is not used [-Wunused-value] keybox-dump.c: In function 'dump_header_blob': keybox-dump.c:155:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:159:7: warning: value computed is not used [-Wunused-value] keybox-dump.c:161:3: warning: value computed is not used [-Wunused-value] keybox-dump.c: In function '_keybox_dump_blob': keybox-dump.c:249:13: warning: value computed is not used [-Wunused-value] keybox-dump.c:253:7: warning: value computed is not used [-Wunused-value] keybox-dump.c:255:3: warning: value computed is not used [-Wunused-value] keybox-dump.c:309:3: warning: value computed is not used [-Wunused-value] keybox-dump.c:404:9: warning: value computed is not used [-Wunused-value] keybox-dump.c: In function '_keybox_dump_find_dups': keybox-dump.c:773:11: warning: value computed is not used [-Wunused-value] kbxutil.c: In function 'dump_fpr': kbxutil.c:319:13: warning: value computed is not used [-Wunused-value] kbxutil.c:326:13: warning: value computed is not used [-Wunused-value] kbxutil.c: In function 'dump_openpgp_key': kbxutil.c:341:3: warning: value computed is not used [-Wunused-value] kbxutil.c:354:11: warning: value computed is not used [-Wunused-value] gpg.c: In function 'main': gpg.c:4073:23: warning: value computed is not used [-Wunused-value] gpg.c:4075:23: warning: value computed is not used [-Wunused-value] gpg.c:4084:17: warning: value computed is not used [-Wunused-value] rmd160.c: In function 'transform': rmd160.c:94:17: warning: assignment discards 'const' qualifier from pointer target type [enabled by default] openfile.c: In function 'copy_options_file': openfile.c:395:15: warning: value computed is not used [-Wunused-value] openfile.c:401:6: warning: value computed is not used [-Wunused-value] sign.c: In function 'sign_file': sign.c:1034:3: warning: value computed is not used [-Wunused-value] trustdb.c: In function 'dump_key_array': trustdb.c:1218:15: warning: value computed is not used [-Wunused-value] trustdb.c:1219:15: warning: value computed is not used [-Wunused-value] tdbdump.c: In function 'list_trustdb': tdbdump.c:83:9: warning: value computed is not used [-Wunused-value] tdbdump.c:84:7: warning: value computed is not used [-Wunused-value] tdbio.c: In function 'tdbio_dump_record': tdbio.c:1171:2: warning: value computed is not used [-Wunused-value] tdbio.c:1177:2: warning: value computed is not used [-Wunused-value] server.c: In function 'gpgsm_status2': server.c:1405:11: warning: value computed is not used [-Wunused-value] server.c:1413:17: warning: value computed is not used [-Wunused-value] server.c:1416:7: warning: value computed is not used [-Wunused-value] certdump.c: In function 'pretty_print_sexp': certdump.c:591:9: warning: value computed is not used [-Wunused-value] certchain.c: In function 'check_cert_policy': certchain.c:396:26: warning: value computed is not used [-Wunused-value] qualified.c: In function 'read_list': qualified.c:86:22: warning: value computed is not used [-Wunused-value] command.c: In function 'cmd_keytocard': command.c:2390:3: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'time_t' [-Wformat] command-ssh.c: In function 'read_control_file_item': command-ssh.c:946:22: warning: value computed is not used [-Wunused-value] genkey.c: In function 'check_passphrase_pattern': genkey.c:143:5: warning: value computed is not used [-Wunused-value] protect-tool.c: In function 'show_keygrip': protect-tool.c:538:3: warning: value computed is not used [-Wunused-value] command.c:74:0: warning: "IS_LOCKED" redefined [enabled by default] In file included from /usr/include/sys/thread.h:37:0, from /usr/include/sys/ptrace.h:28, from /usr/include/sys/proc.h:48, from /usr/include/sys/pri.h:43, from /usr/include/sys/sched.h:38, from /usr/include/sched.h:51, from /opt/lib/gcc/powerpc-ibm-aix5.3.7.0/4.7.4/include-fixed/pthread.h:73, from /opt/include/npth.h:61, from command.c:30: /usr/include/sys/lock_def.h:224:0: note: this is the location of the previous definition g13.c: In function 'wrong_args': g13.c:243:3: warning: value computed is not used [-Wunused-value] server.c: In function 'g13_status': server.c:702:11: warning: value computed is not used [-Wunused-value] server.c:710:17: warning: value computed is not used [-Wunused-value] server.c:713:7: warning: value computed is not used [-Wunused-value] mount.c: In function 'g13_mount_container': mount.c:263:7: warning: implicit declaration of function 'mkdtemp' [-Wimplicit-function-declaration] be-encfs.c: In function 'be_encfs_create_container': be-encfs.c:418:3: warning: implicit declaration of function 'mkdtemp' [-Wimplicit-function-declaration] dirmngr.c:361:1: warning: 'my_gnutls_log' defined but not used [-Wunused-function] dirmngr-client.c: In function 'read_pem_certificate': dirmngr-client.c:586:13: warning: value computed is not used [-Wunused-value] dirmngr-client.c:595:24: warning: value computed is not used [-Wunused-value] dirmngr-client.c:598:24: warning: value computed is not used [-Wunused-value] dirmngr-client.c:606:30: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c: In function 'read_and_print_response': gpg-connect-agent.c:2008:15: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2031:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2044:25: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2056:25: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2058:25: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2060:25: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2062:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2088:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2095:15: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2103:17: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2114:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2124:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2142:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2156:19: warning: value computed is not used [-Wunused-value] gpg-connect-agent.c:2168:19: warning: value computed is not used [-Wunused-value] watchgnupg.c: In function 'die': watchgnupg.c:68:3: warning: value computed is not used [-Wunused-value] watchgnupg.c: In function 'err': watchgnupg.c:85:3: warning: value computed is not used [-Wunused-value] watchgnupg.c: In function 'print_line': watchgnupg.c:165:11: warning: value computed is not used [-Wunused-value] gpgparsemail.c: In function 'die': gpgparsemail.c:94:3: warning: value computed is not used [-Wunused-value] gpgparsemail.c: In function 'err': gpgparsemail.c:112:3: warning: value computed is not used [-Wunused-value] gpgparsemail.c: In function 'run_gnupg': gpgparsemail.c:254:13: warning: value computed is not used [-Wunused-value] gpgparsemail.c:269:11: warning: value computed is not used [-Wunused-value] gpgparsemail.c:290:7: warning: value computed is not used [-Wunused-value] gpg-check-pattern.c: In function 'process': gpg-check-pattern.c:465:16: warning: value computed is not used [-Wunused-value] clean-sat.c: In function 'main': clean-sat.c:27:15: warning: value computed is not used [-Wunused-value] clean-sat.c:30:2: warning: value computed is not used [-Wunused-value] clean-sat.c:31:6: warning: value computed is not used [-Wunused-value] mk-tdata.c: In function 'main': mk-tdata.c:56:11: warning: value computed is not used [-Wunused-value] mk-tdata.c:65:11: warning: value computed is not used [-Wunused-value] gpgsplit.c: In function 'read_u16': gpgsplit.c:219:13: warning: value computed is not used [-Wunused-value] gpgsplit.c:222:13: warning: value computed is not used [-Wunused-value] gpgsplit.c: In function 'write_old_header': gpgsplit.c:254:8: warning: value computed is not used [-Wunused-value] gpgsplit.c:259:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:261:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:266:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:269:7: warning: value computed is not used [-Wunused-value] gpgsplit.c: In function 'write_new_header': gpgsplit.c:277:8: warning: value computed is not used [-Wunused-value] gpgsplit.c:282:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:288:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:290:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:295:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:297:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:299:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:301:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:303:11: warning: value computed is not used [-Wunused-value] gpgsplit.c: In function 'handle_zlib': gpgsplit.c:392:29: warning: value computed is not used [-Wunused-value] gpgsplit.c:439:12: warning: value computed is not used [-Wunused-value] gpgsplit.c:451:5: warning: value computed is not used [-Wunused-value] gpgsplit.c: In function 'write_part': gpgsplit.c:572:15: warning: value computed is not used [-Wunused-value] gpgsplit.c:596:16: warning: value computed is not used [-Wunused-value] gpgsplit.c:608:16: warning: value computed is not used [-Wunused-value] gpgsplit.c:626:25: warning: value computed is not used [-Wunused-value] gpgsplit.c:639:24: warning: value computed is not used [-Wunused-value] gpgsplit.c:659:24: warning: value computed is not used [-Wunused-value] gpgsplit.c:665:28: warning: value computed is not used [-Wunused-value] gpgsplit.c:667:24: warning: value computed is not used [-Wunused-value] gpgsplit.c:681:20: warning: value computed is not used [-Wunused-value] gpgsplit.c:688:19: warning: value computed is not used [-Wunused-value] gpgsplit.c:691:20: warning: value computed is not used [-Wunused-value] gpgsplit.c:702:24: warning: value computed is not used [-Wunused-value] gpgsplit.c:729:26: warning: value computed is not used [-Wunused-value] gpgsplit.c:731:24: warning: value computed is not used [-Wunused-value] gpgsplit.c:742:12: warning: value computed is not used [-Wunused-value] gpgsplit.c:749:11: warning: value computed is not used [-Wunused-value] gpgsplit.c:752:12: warning: value computed is not used [-Wunused-value] gpgsplit.c: In function 'do_split': gpgsplit.c:788:9: warning: value computed is not used [-Wunused-value] gpgsplit.c:801:16: warning: value computed is not used [-Wunused-value] gpgsplit.c:810:20: warning: value computed is not used [-Wunused-value] gpgsplit.c:849:24: warning: value computed is not used [-Wunused-value] yat2m: writing 'gnupg.7' yat2m: writing 'gpg2.1' yat2m: writing 'gpgsm.1' yat2m: writing 'gpg-agent.1' yat2m: writing 'dirmngr.8' yat2m: writing 'scdaemon.1' yat2m: writing 'watchgnupg.1' yat2m: writing 'gpgv2.1' yat2m: writing 'addgnupghome.8' yat2m: writing 'gpgconf.1' yat2m: writing 'applygnupgdefaults.8' yat2m: writing 'gpgsm-gencert.sh.1' yat2m: writing 'gpg-preset-passphrase.1' yat2m: writing 'gpg-connect-agent.1' yat2m: writing 'dirmngr-client.1' yat2m: writing 'gpgparsemail.1' yat2m: writing 'symcryptrun.1' yat2m: writing 'gpg-zip.1' asschk.c: In function 'die': asschk.c:197:3: warning: value computed is not used [-Wunused-value] asschk.c: In function 'err': asschk.c:218:3: warning: value computed is not used [-Wunused-value] asschk.c: In function 'read_assuan': asschk.c:316:6: warning: value computed is not used [-Wunused-value] asschk.c: In function 'start_server': asschk.c:454:7: warning: missing sentinel in function call [-Wformat] gpgsm: WARNING: running with faked system time: 2002-12-02 13:29:59 gpgsm: keybox '/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/pubring.kbx' created gpgsm: total number processed: 1 gpgsm: imported: 1 gpgsm: WARNING: running with faked system time: 2002-12-02 13:29:59 gpgsm: total number processed: 1 gpgsm: imported: 1 gpgsm: WARNING: running with faked system time: 2002-12-02 13:29:59 gpgsm: total number processed: 1 gpgsm: imported: 1 On Thu, Nov 27, 2014 at 6:40 PM, Michael Felt wrote: > I decided to be a bit more pragmatic, and just packaged and loaded > libiconv-1.14. > > Now configure completes, but make fails (with xlC or vac) on: > + /opt/bin/make > build/aix/make.out > "http.c", line 1931.1: 1506-343 (S) Redeclaration of parse_response > differs from previous declaration on line 181 of "http.c". > "http.c", line 1931.1: 1506-050 (I) Return type "enum {...}" in > redeclaration is not compatible with the previous return type "unsigned > int". > make[3]: *** [libcommontls_a-http.o] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > /opt/bin/make returned an error > > There may be more messages (to come), but this is where it stops for now. > > Michael > > p.s. My last note was only to the list. Did it show up? (I shall go > register - now while I think of it!) > > On Mon, Nov 24, 2014 at 12:51 PM, Werner Koch wrote: > >> On Sat, 22 Nov 2014 16:30, aixtools at gmail.com said: >> >> > However, configure is reporting - in config.log that AIX does not have >> > libiconv - which it does. So, my question is: to which gnu tool should I >> >> Well, the code does not detect it or it is not usable. The latter >> should be reported. >> >> The detection code is source copied in GnuPG and used to create the >> configure script. Some parts have not been updated for a long time and >> thus it might help to update them. Can you send me the complete >> config.log by private mail? >> >> >> Shalom-Salam, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aixtools at gmail.com Thu Nov 27 19:03:09 2014 From: aixtools at gmail.com (Michael Felt) Date: Thu, 27 Nov 2014 19:03:09 +0100 Subject: GnuPG 2.1.0 "modern" released In-Reply-To: <87d28cg6k1.fsf@vigenere.g10code.de> References: <87ioisn1mo.fsf@vigenere.g10code.de> <87d28cg6k1.fsf@vigenere.g10code.de> Message-ID: what does the test t-exeche do, besides spin on the processor (after saying PASS: t-zb32 max. file descriptors: 2147483647 Michael On Mon, Nov 24, 2014 at 12:51 PM, Werner Koch wrote: > On Sat, 22 Nov 2014 16:30, aixtools at gmail.com said: > > > However, configure is reporting - in config.log that AIX does not have > > libiconv - which it does. So, my question is: to which gnu tool should I > > Well, the code does not detect it or it is not usable. The latter > should be reported. > > The detection code is source copied in GnuPG and used to create the > configure script. Some parts have not been updated for a long time and > thus it might help to update them. Can you send me the complete > config.log by private mail? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samir at samirnassar.com Fri Nov 28 09:16:30 2014 From: samir at samirnassar.com (Samir Nassar) Date: Fri, 28 Nov 2014 10:16:30 +0200 Subject: For Your Information: Circumvention Tech Festival - March 1 - 6 Message-ID: <1520474.iciEaXXyqn@forge> The Circumvention Tech Festival (CTFestival) gathers the community fighting censorship and surveillance for a week of conferences, workshops, hackathons, and social gatherings, featuring many of the Internet Freedom community's flagship events. Specifically, the festival enables the Circumvention Tech community to pool resources, share knowledge, and network. Developers can interact with on-the- ground activists; journalists can exchange stories with humanitarian workers; funders can meet end-users; and so forth. Notably, the festival will feature two community-run series - one in English and one in Spanish - offering space for projects and individuals to host their own talks, hackathons, panel discussions, trainings, etc. The festival will also feature public events designed to familiarize the local Valencian community with the circumvention tech field. https://openitp.org/festival/circumvention-tech-festival.html -- Samir Nassar samir at samirnassar.com https://samirnassar.com PGP Fingerprint: EE76 B39E 0778 8F95 F796 B044 FE67 9A90 8E99 7AB2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From ndk.clanbo at gmail.com Fri Nov 28 11:41:20 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 28 Nov 2014 11:41:20 +0100 Subject: Randomized hashing In-Reply-To: <54772AFB.4050806@digitalbrains.com> References: <87mw7e3x7i.fsf@vigenere.g10code.de> <547626EF.9010103@digitalbrains.com> <54762AA5.8080302@gmail.com> <54762C75.6080607@digitalbrains.com> <5476BCD6.2010007@gmail.com> <5476F7C7.2070209@digitalbrains.com> <5476FCC2.70701@digitalbrains.com> <54771347.5080609@gmail.com> <54772AFB.4050806@digitalbrains.com> Message-ID: <54785150.7050602@gmail.com> Il 27/11/2014 14:45, Peter Lebbing ha scritto: > On 27/11/14 13:04, NdK wrote: >> (note that r is not signed, as the rhash scheme suggests and the paper >> confirms!) > >> "In contrast to a previous proposal by the same authors, the salt r does not >> need to be included under the signature." > > I read this quite differently. I read it as that 'r' is not included in the > signature, that is, what is signed is still just the hash. It seems profoundly > silly to not include it in the signed data, for the reasons you mention. Can you > give a quote that actually says 'r' is not included in the signed data? When it says that 'r' have to be sent separately. It's 'included' only indirectly in the hash calculation. >> At a first glance, it would be safer to have r *inside* the signature. > Oh, I agree, I already thought that might close any 'r'-swapping security > issues, if there would be any; just like you can include the hash > algorithm in the signature to prevent swapping it out for a weaker one. But when > swapping 'r''s does not actually create any security issues, it just makes > things needlessly complicated. I don't understand you. I said that if you have a short message (less than hash len) it's trivial for an attacker to fix a new M' and calculate a new r' value that satisfies r xor M == r' xor M' . It gets harder with longer messages. > To use your smartcard example: the smartcard only > accepts a specifically formatted message. If you change that message to now > include a new value, you would need a new smartcard. Furthermore, the size of > 'r' might pose a problem; it's a significant addition to the data structure that > is signed. Depends on how strict the checking is. E.g., if the smartcard only uses the raw buffer you pass it (just adding the needed padding before signing) and is able to accept SHA-512, then you could just use SHA-256 and append 256bits of 'r' w/o having to change the smartcard: it sees 512bits and pads 'em like in SHA-512. That's one of the reasons I like the cards that do the last hash round more. >> Maybe it's just a performance issue? > I suppose also simplicity, verifiability, implementation cost... Probably. > The rest seems unrelated to randomized hashing except for what I already > mentioned: that including 'r' in the signature would mean you can't use an > existing OpenPGP card. But I'll answer anyway. I didn't study OpenPGP card protocol enough. >> while the op is anyway 'RSA encrypt', the padding should be different if >> you're signing an hash or exchanging a session key. Failing to let the card >> do the padding could lead to exposure of the private key, IIRC. > I think you mean "RSA decrypt", for signing you use the "RSA decrypt" primitive, > just as you use to decrypt a session key. Yup. Terminology slip. The RSA op involving the private key, so sign/decrypt. > But this is all already done in the OpenPGP card. It checks the data to be > signed conforms to PKCS#1; it is optional to check the DigestInfo, but the rest > of the data structure already differentiates it from an encrypted session key. > It will only let you sign with the "Signing" and "Authentication" keys. > Likewise, it checks that the output of decrypting with the "Decryption" key > conforms to the PKCS#1 format, so you can't fool it into a signing operation either. Ok. BYtE, Diego From gnupgpack at on.yourweb.de Fri Nov 28 15:04:56 2014 From: gnupgpack at on.yourweb.de (gnupgpack at on.yourweb.de) Date: Fri, 28 Nov 2014 15:04:56 +0100 Subject: Setpref is not working or is it a bug or something? Message-ID: <2815A2.54788F19.0002@gate> Hello, > -----Original Message----- > From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of > Robin Mathew Rajan > Sent: Thursday, November 27, 2014 8:39 AM > That's why I chose, these four extra configurations which I believe most > secure with fewer compatibility issues with newer releases of OpenPGP > implementations and other softwares. These preferences won't break the > OpenPGP implementation, but at the same time, offers high security too. > > default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 CAMELLIA256 > TWOFISH AES192 CAMELLIA192 CAMELLIA128 AES CAST5 IDEA BZIP2 ZLIB ZIP > personal-cipher-preferences AES256 CAMELLIA256 TWOFISH > personal-digest-preferences SHA512 > personal-compress-preferences BZIP2 Thanks to all contributors for this useful discussion and hints! > -----Original Message----- > From: Peter Lebbing [mailto:peter at digitalbrains.com] > Sent: Wednesday, November 26, 2014 8:16 PM > To: gnupgpack at on.yourweb.de; gnupg-users at gnupg.org > Also, @g, as you > apparently call yourself, you seem to start a new thread with each post, > could you try to get your e-mail client to properly thread?) I am sorry, all my replies are sent to gnupg-users at gnupg.org only, without touching the subject. I am new to mailing lists, so is this the right procedure? Thanks once more, Chris From kardan38 at gmail.com Fri Nov 28 19:26:37 2014 From: kardan38 at gmail.com (Salih Kardan) Date: Fri, 28 Nov 2014 20:26:37 +0200 Subject: How can I configure gpg-agent to run at system start-up? Message-ID: Hello everyone, I am a newbie to GnuPG, and just wanted to use gpg-agent for ssh into my server machines. I build GnuPG from source and using 2.1.0 version. I followed the instructions described in this mailing list thread , everything worked fine. I want gpg-agent start automatically after every reboot, so I wrote a small init script to start gpg-agent. After reboot gpg-agent starts working, however when I run ssh command, I get *"Agent admitted failure to sign using the key"* error. (If I start agent manually, I don't get this error). How is different starting gpg-agent manually from starting it inside a bash script during system start-up? FYI, I also tried to use upstart script distributed within gnupg-agent Ubuntu package, it also did not work. How can I configure gpg-agent to run at system start-up? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Nov 28 21:52:38 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 28 Nov 2014 21:52:38 +0100 Subject: How can I configure gpg-agent to run at system start-up? In-Reply-To: (Salih Kardan's message of "Fri, 28 Nov 2014 20:26:37 +0200") References: Message-ID: <87egsn1209.fsf@vigenere.g10code.de> On Fri, 28 Nov 2014 19:26, kardan38 at gmail.com said: > I want gpg-agent start automatically after every reboot, so I wrote a > small Just don't do that. > init script to start gpg-agent. After reboot gpg-agent starts working, > however when I run ssh command, I get *"Agent admitted failure to sign > using the key"* error. (If I start agent manually, I don't get this error). > How is different starting gpg-agent manually from starting it inside a bash > script during system start-up? ssh is special because it does not known about GnuPG. In this case you may simply do that gpgconf --launch gpg-agent (for 2.1 only, for 2.0 you need to use gpg-connect-agent) > How can I configure gpg-agent to run at system start-up? Not at system startup but at login time (.bashrc in interactive mode) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kloecker at kde.org Fri Nov 28 22:15:51 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 28 Nov 2014 22:15:51 +0100 Subject: Randomized hashing In-Reply-To: <54774CE0.5020703@gmail.com> References: <5476FCC2.70701@digitalbrains.com> <54774CE0.5020703@gmail.com> Message-ID: <1716984.hyPl3tR9J7@collossus.ingo-kloecker.de> On Thursday 27 November 2014 17:10:08 NdK wrote: > Il 27/11/2014 11:28, Peter Lebbing ha scritto: > > [Resending to list] > > > Perhaps I should add that it takes real research and formal proof to show > > that this randomized hashing doesn't add attack vectors, and I have been > > glossing over that. But that is because at a glance it looks like such > > research has been done. That doesn't mean it's a fact that there are no > > significant attack vectors, but it does give the scheme credibility. > > Well, I'm no expert, but it gives me the feeling of being potentially > dangerous, since once the attacker have your signature for a document > s=E(Prk, H(RMX(M,r))) , r > (note that r is not signed, as the rhash scheme suggests and the paper > confirms!) he *might* be able to calculate r' so that RMX(M',r') == > RMX(M,r) then 'recycle' your signature for M'. Remember that RMX is > proposed to be a simple block-xor! For very short (less than a single > hash block) messages it's trivial, if I'm not badly mislead by the > graphic description in the site: > RMX(0, 1) == RMX(1, 0) I think you missed that according to the diagram RMX(M, r) = (r, ...), i.e. it starts with r. Consequently, RMX(M',r') = RMX(M,r) => (M',r') = (M,r), i.e. RMX is injective. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From steve at sawczyn.com Fri Nov 28 21:33:22 2014 From: steve at sawczyn.com (Steven M. Sawczyn) Date: Fri, 28 Nov 2014 14:33:22 -0600 Subject: Can I convert a V3 key and is it even worth doing? Message-ID: <028001d00b4a$8e3e7e10$aabb7a30$@Sawczyn.com> Hello everyone, I have a rather strange problem on which I could use some advice. I am starting to use GnuPG again after a number of years and to that end, have resurrected my original key generated with PGP back in 1998. For the most part this key works well although since it's an older V3 key, certain software packages have trouble importing the secret portion of it. To be fair it's not like hundreds of people have my key, however, this key is available on public servers and I like the fact that it's really the only key associated with me. My questions are: 1. Is there any way to convert my V3 key to something newer? My guess is no, but ideally I'm wrong about this. 2. Other than my experiencing problems with applications that don't support the V3 key, is there any other really compelling reason to abandon it in favor of a brand new one? 3. If generating a new key is the best way to go, is there any way to get rid of the older key off servers? I could generate a revocation certificate, however my understanding is that won't really get rid of anything and my concern is that having two keys with the same Email address could lead to confusion. Thanks in advance for any help with this, I'm excited to be using GnuPG again and want to make sure I get things working as well as possible before trying to introduce others to it. Thanks, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Fri Nov 28 22:26:55 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 28 Nov 2014 22:26:55 +0100 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <2815A2.54788F19.0002@gate> References: <2815A2.54788F19.0002@gate> Message-ID: <4284910.X4Ik0BQkaD@collossus.ingo-kloecker.de> On Friday 28 November 2014 15:04:56 gnupgpack at on.yourweb.de wrote: > > -----Original Message----- > > From: Peter Lebbing [mailto:peter at digitalbrains.com] > > Sent: Wednesday, November 26, 2014 8:16 PM > > To: gnupgpack at on.yourweb.de; gnupg-users at gnupg.org > > Also, @g, as you > > apparently call yourself, you seem to start a new thread with each post, > > could you try to get your e-mail client to properly thread?) > > I am sorry, all my replies are sent to gnupg-users at gnupg.org only, > without touching the subject. > I am new to mailing lists, so is this the right procedure? Yes, that's the right procedure. The problem Peter mentioned is caused by the fact that your replies lack the message headers (In-reply-to and References) that usually link replies to the replied-to messages. It seems that either your mail client doesn't add those message headers or that the GPGrelay thingy that you appear to be using removes those message headers. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri Nov 28 22:38:51 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 28 Nov 2014 16:38:51 -0500 Subject: Can I convert a V3 key and is it even worth doing? In-Reply-To: <028001d00b4a$8e3e7e10$aabb7a30$@Sawczyn.com> References: <028001d00b4a$8e3e7e10$aabb7a30$@Sawczyn.com> Message-ID: <5478EB6B.9090904@fifthhorseman.net> On 11/28/2014 03:33 PM, Steven M. Sawczyn wrote: > Hello everyone, I have a rather strange problem on which I could use some > advice. I am starting to use GnuPG again after a number of years and to > that end, have resurrected my original key generated with PGP back in 1998. > For the most part this key works well although since it's an older V3 key, > certain software packages have trouble importing the secret portion of it. > To be fair it's not like hundreds of people have my key, however, this key > is available on public servers and I like the fact that it's really the only > key associated with me. My questions are: > > 1. Is there any way to convert my V3 key to something newer? My guess > is no, but ideally I'm wrong about this. I'm sure it's possible to do. I don't think it's a good idea. For one thing, if you converted it, the OpenPGPv4 fingerprint would be a different fingerprint than the v3 key, so it would appear as a different key to most people anyway. You might as well create a new key. > 2. Other than my experiencing problems with applications that don't > support the V3 key, is there any other really compelling reason to abandon > it in favor of a brand new one? Yes. the OpenPGPv3 key fingerprint mechanism is trivial to spoof. OpenPGPv3 also implies the use of MD5 as a digest algorithm for signatures. > 3. If generating a new key is the best way to go, is there any way to > get rid of the older key off servers? I could generate a revocation > certificate, however my understanding is that won't really get rid of > anything and my concern is that having two keys with the same Email address > could lead to confusion. lots of us have historical keys on the keyservers. It's not a problem worth worrying about. Looking on the public keyservers, there appear to already be 3 different keys with your e-mail address, so adding one more (that was made this millenium) doesn't seem like it's particularly worrisome.. And if it makes you feel any better(?) anyone can upload another key with your user ID attached to it. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Nov 29 04:27:49 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 28 Nov 2014 22:27:49 -0500 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <5476D51C.6070201@robinmathewrajan.com> References: <5476BC01.9050708@robinmathewrajan.com> <5476D51C.6070201@robinmathewrajan.com> Message-ID: <54793D35.7050507@sixdemonbag.org> > You can delete these values from your current gpg.conf. > > s2k-digest-algo SHA256 s2k-cipher-algo AES256 cert-digest-algo SHA256 > digest-algo SHA256 > > Reason 1: Those values are used when options like > 'personal-cipher-preferences', 'personal-digest-preferences' and > 'personal-compress-preferences' are not given! But here, you already > gave those three options already. This isn't quite true. personal-*-preferences won't affect s2k preferences or cert-digest-algo. However, you're absolutely correct to advise against using cipher-algo or digest-algo. (I *think* I'm right on this, but I can't promise I am, nor have I done a quick empirical test to check. Take the preceding with a grain of salt.) > Reason 2: Those values are known to break the OpenPGP standard. Some of them are serious problems (digest-algo and cipher-algo). The others are mostly safe. s2k is only used by the user on their own machine, so there isn't much concern about interoperability with other OpenPGP clients. > That's the same OpenPGP does. OpenPGP standard is just a reference > model. Anyone can modify it and include unique features. But it's > not necessary to be those 'unique features' to be included in every > OpenPGP implemented products. But when it comes to communicating > each other, there comes the problem if there's no common standard > rule. Those who are concerned about OpenPGP conformance should add "openpgp" to the end of their gpg.conf file. :) > But at the same time, these settings might be incompatible with > older softwares. Nope! The preference list you gave will not cause troubles with any OpenPGP application, not even old PGP 5.x. If there's no preference list on your recipient's public key (which does happen, from time to time), OpenPGP will gracefully degrade to use SHA-1 and 3DES. SHA-1 is getting pretty long in the tooth, but 3DES is still solid as a rock. My usual joke about 3DES -- which, like most of my jokes, is a way of telling truth with a laugh -- is that 3DES has all the beauty of a Soviet workers' housing bloc, all the aesthetics of the Socialist Realism school of art, and yet has been turning brilliant young cryptanalysts into burned-out alcoholic wrecks for the last 35 years. :) From bxstover at yahoo.co.uk Sat Nov 29 07:13:03 2014 From: bxstover at yahoo.co.uk (Ben Stover) Date: Sat, 29 Nov 2014 07:13:03 +0100 Subject: Difference Kleopatra vs WinPT Message-ID: <695838.99198.bm@smtp105.mail.ir2.yahoo.com> As far as I can see Kleopatra and WinPT are similar, competing tools for the same purpose: Management of pgp keys & certificates. What are the differences in details? Which one is better/more used? Ben From aarcane at aarcane.org Sat Nov 29 09:10:15 2014 From: aarcane at aarcane.org (Schlacta, Christ) Date: Sat, 29 Nov 2014 00:10:15 -0800 Subject: Difference Kleopatra vs WinPT In-Reply-To: <695838.99198.bm@smtp105.mail.ir2.yahoo.com> References: <695838.99198.bm@smtp105.mail.ir2.yahoo.com> Message-ID: You're confusing gpa and winpt. Gpa is the default utility included with winpt, but kleopatra is also included with winpt. Comparison wise, kleo has more features, but gpa's futures are more... useful? I find myself using gpa daily, and kleopatra only on rare occasion On Nov 28, 2014 11:41 PM, "Ben Stover" wrote: > As far as I can see Kleopatra and WinPT are similar, competing tools for > the same purpose: > > Management of pgp keys & certificates. > > What are the differences in details? > > Which one is better/more used? > > Ben > > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.jackson at nordnet.fr Sun Nov 30 00:23:26 2014 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sun, 30 Nov 2014 00:23:26 +0100 Subject: Keygrip v fingerprint ? Message-ID: <547A556E.30504@nordnet.fr> I see on : https://www.gnupg.org/documentation/manuals/gnupg/Option-Index.html#Option-Index references to both --with-keygrip and --with-fingerprint. When I try --with-keygrip on gnupg2.0.26, it appears not to be a valid option. The only other time I have seen a reference to a keygrip (and I don't remember where I saw it), it seemed to me that a keygrip looked just like a fingerprint. Could someone please explain the difference between a keygrip and a fingerprint or point me to a relevant document ? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Sun Nov 30 01:32:57 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 30 Nov 2014 01:32:57 +0100 Subject: Keygrip v fingerprint ? In-Reply-To: <547A556E.30504@nordnet.fr> References: <547A556E.30504@nordnet.fr> Message-ID: <547A65B9.8060600@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/30/2014 12:23 AM, Philip Jackson wrote: > I see on : > > https://www.gnupg.org/documentation/manuals/gnupg/Option-Index.html#Option-Index > > references to both --with-keygrip and --with-fingerprint. When I > try --with-keygrip on gnupg2.0.26, it appears not to be a valid > option. > It is available in 2.1 > The only other time I have seen a reference to a keygrip (and I > don't remember where I saw it), it seemed to me that a keygrip > looked just like a fingerprint. > > Could someone please explain the difference between a keygrip and a > fingerprint or point me to a relevant document ? The keygrip is protocol-agnostic whereby the fingerprint would differ e.g. between OpenPGP and X.509. From [0] (note "[2]"): The keygrip is a unique identifier for a key pair, it is independent of any protocol, so that the same key can be used with different protocols. PKCS-15 calls this a subjectKeyHash; it can be calculated using Libgcrypt's gcry_pk_get_keygrip (). References: [0] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/keyformat.txt;h=42c4b1f06faf1bbe71ffadc2fee0fad6bec91a97;hb=refs/heads/master - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "I have always wished that my computer would be as easy to use as my telephone. My wish has come true -- I no longer know how to use my telephone" (Bjarne Stroustrup, April 1999) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUemW3AAoJEPw7F94F4Tag29IP/iO+JvAlFBZyqgF5Juf+F005 iCHj7piTb5uTKFHCS+tZl481HCet1dEti8JUlQBYq5G7HAKfwWGvSsg3XSg+bpJu s9UM3JQpC4Nc+rxVqyYkB6rwPRCdWHiJgVV9vCBX9WzRfLT4TkVBVarMRWl7v6mx mUspI9PAm3pHVS9Sp4ehvLaDH+0tew3sCGeMLa6F4tvEcjtl6v9TXEtlsmJaBE0R 4m945ik6rAidSLVViCHBBL28UmKsXgho0YHP1fINT3nrmqojesZhqSwQ/dGL3Ppn 9Jcqiz7jLJAmx3pwBgeOV5kzFLE0iWS4x6bwNLaopjI0gM2U/ccuH3HVKbl0xu0w Ki+z9U1eLXc2zxuGrc7M0bVjcGt72pdODPf2HNUzYeFlTcX6mmIRRVGydoKbvQBB o84Io2pIjprCcC07lqyWU8lB6QaNHHrJ/cp1NVSfPhnxfpnPLW3u62K/2WXiWfMJ aztfgWSIFNjrFUY01ayQj/OePei6V4FRQa9G13PSCF8C+6ESNOvLL7FpeAqQM9Es H0I8FjWmBpVfbamuNiQxZymwN2Rc0FknGHxpwvWcZEu6PUJUyY2PtNmWwKd7nvpq rYfp9okBRs0TCIAs0XRuF0RepwbVcbr9Z2Kxy5vqE3XsSZ5B9a4zU7OzGIoqkcH5 UQtfRrgLvyVpIiEgWq8V =ZaEC -----END PGP SIGNATURE----- From mail at robinmathewrajan.com Sun Nov 30 03:10:21 2014 From: mail at robinmathewrajan.com (Robin Mathew Rajan) Date: Sun, 30 Nov 2014 07:40:21 +0530 Subject: Setpref is not working or is it a bug or something? In-Reply-To: <54793D35.7050507@sixdemonbag.org> References: <5476BC01.9050708@robinmathewrajan.com> <5476D51C.6070201@robinmathewrajan.com> <54793D35.7050507@sixdemonbag.org> Message-ID: <547A7C8D.2020909@robinmathewrajan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi bro, :) Thanks for correcting me. Regards! :) Robin Mathew Rajan On 29-11-2014 AM 08:57, Robert J. Hansen wrote: >> You can delete these values from your current gpg.conf. >> >> s2k-digest-algo SHA256 s2k-cipher-algo AES256 cert-digest-algo SHA256 >> digest-algo SHA256 >> >> Reason 1: Those values are used when options like >> 'personal-cipher-preferences', 'personal-digest-preferences' and >> 'personal-compress-preferences' are not given! But here, you already >> gave those three options already. > > This isn't quite true. personal-*-preferences won't affect s2k > preferences or cert-digest-algo. However, you're absolutely correct to > advise against using cipher-algo or digest-algo. > > (I *think* I'm right on this, but I can't promise I am, nor have I done > a quick empirical test to check. Take the preceding with a grain of salt.) > >> Reason 2: Those values are known to break the OpenPGP standard. > > Some of them are serious problems (digest-algo and cipher-algo). The > others are mostly safe. s2k is only used by the user on their own > machine, so there isn't much concern about interoperability with other > OpenPGP clients. > >> That's the same OpenPGP does. OpenPGP standard is just a reference >> model. Anyone can modify it and include unique features. But it's >> not necessary to be those 'unique features' to be included in every >> OpenPGP implemented products. But when it comes to communicating >> each other, there comes the problem if there's no common standard >> rule. > > Those who are concerned about OpenPGP conformance should add "openpgp" > to the end of their gpg.conf file. :) > >> But at the same time, these settings might be incompatible with >> older softwares. > > Nope! The preference list you gave will not cause troubles with any > OpenPGP application, not even old PGP 5.x. If there's no preference > list on your recipient's public key (which does happen, from time to > time), OpenPGP will gracefully degrade to use SHA-1 and 3DES. SHA-1 is > getting pretty long in the tooth, but 3DES is still solid as a rock. > > My usual joke about 3DES -- which, like most of my jokes, is a way of > telling truth with a laugh -- is that 3DES has all the beauty of a > Soviet workers' housing bloc, all the aesthetics of the Socialist > Realism school of art, and yet has been turning brilliant young > cryptanalysts into burned-out alcoholic wrecks for the last 35 years. :) > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJUenyNAAoJEJyRZAJNoXmulPYP/jWu0Om3Jt2FIZwWc65cPlbz odJrDeQvzwJ0b03xtJy5B1e42cIRfSZVNkLpUP8ajxdbH/ISgraXtEmhZwyZwIfg Rnx986Mnrb5kT9eY1JbBLYVm20Exq9nwkrvoMjbWnJESJxbqcNYKYcAIjZkRAHqd ow3um/OGlY/HS+t/0Q92d6TRfaLkJxhmIw6EqwutFuQ44MUd3no9I5J0sn1CnGXG 0twX2h6IXAlzPEBJz2eMSjpmwEDVLHzzMw7UixVc8jOjlf+uk1XboZZgxiaEXZAq ydycXICFI8rVtQQmKDgVuBQvFLUYC4ZInKFDM/qTEgi4r1bs3XGzoBk2y8BJxep+ q0lDeNvXDyZXRXms0Ga0aWUaJ29pfS95/nKqaF7/ndFNOVNS3/oXgAuS2uRs9s5l BRp2wWb7S82H5ueLffhNAvHTgq2vffDglNrm+TrAHyUw48H0Fsx0TsVjlgotAx+x 5yGcf5MzAxlpEa4FpcUZN1xjto3sh5/Q57bCFAsYoVbbkuyTsvPBD1FUzwY8SlC7 R1M7c0xLhO96NsKEQVdz7HQW0yE2jF4ZBsBcSUc7wzIvCEIKdtO6U9mQYOhJ9Fx1 HjUTRnLlPv3h+/D4GR4CQjER6LF5xGjXMaSWl6v83uUsVTL4tSKo/ZbgLszSh3TD rGhlmAvGGfwFpL8zf0nS =HQCO -----END PGP SIGNATURE----- From gnupgpack at on.yourweb.de Sun Nov 30 10:46:40 2014 From: gnupgpack at on.yourweb.de (gnupgpack at on.yourweb.de) Date: Sun, 30 Nov 2014 10:46:40 +0100 Subject: Setpref is not working or is it a bug or something? Message-ID: <3ABF0B.547AF592.0006@gate> >> I am sorry, all my replies are sent to gnupg-users at gnupg.org only, > Yes, that's the right procedure. > The problem Peter mentioned is caused by the fact that your replies lack > the message headers (In-reply-to and References) that usually link > replies to the replied-to messages. Yes, that's true, SMTP-Filter is running for outgoing mails: http://lab1.de/Central/Software/Internet/E-Mail/SMTP-Filter/ It deletes for security/privacy reasons: IN-REPLY-TO: MESSAGE-ID: ORGANIZATION: REFERENCES: THREAD-INDEX: THREAD-TOPIC: X-MAILER: X-MIMEOLE: X-MSMAIL-PRIORITY: X-Relayed-By: GPGrelay Hidden header 'In-Reply-To: <1CD78A.547AEDEA.0002 at machine>': IN-REPLY-TO and REFERENCES for example include ... at machine, which is always the same... This is not wanted because of the possibility of tracking cross over the web ("who posts which content...") So, how to deal with this behavior? Keeping subject untouched seems to be enough for identifying and associating to thread, isn't it? Thanks + regards, Chris From philip.jackson at nordnet.fr Sun Nov 30 11:57:33 2014 From: philip.jackson at nordnet.fr (Philip Jackson) Date: Sun, 30 Nov 2014 11:57:33 +0100 Subject: Keygrip v fingerprint ? In-Reply-To: <547A65B9.8060600@sumptuouscapital.com> References: <547A556E.30504@nordnet.fr> <547A65B9.8060600@sumptuouscapital.com> Message-ID: <547AF81D.6050802@nordnet.fr> On 30/11/14 01:32, Kristian Fiskerstrand wrote: > The keygrip is protocol-agnostic whereby the fingerprint would differ > e.g. between OpenPGP and X.509. From [0] (note "[2]"): > > The keygrip is a unique identifier for a key pair, it is > independent of any protocol, so that the same key can be used with > different protocols. PKCS-15 calls this a subjectKeyHash; it can be > calculated using Libgcrypt's gcry_pk_get_keygrip (). Thank you, Kristian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From gnupgpack at on.yourweb.de Sun Nov 30 20:21:09 2014 From: gnupgpack at on.yourweb.de (gnupgpack at on.yourweb.de) Date: Sun, 30 Nov 2014 20:21:09 +0100 Subject: Order/changing of subkeys derogates compatibility!? Message-ID: <7B3B0E.547B7C39.0002@gate> Hello to all, while creating some new v4-RSA keypairs a compatibility issue occurs with old PGP-6.5.x: C,E should be RSA, S should be DSA (2048 with SHA256 for smaller signatures...) Sec/pub keyset is used with GPG-1.4.18 (Win7-64), pub key is exported to PGP-6.5.x only for testing purpose on another machine. First attempt, everything is working in PGP-6.5.x too: pub 3072R/D956D57E erzeugt: 2014-11-30 verf?llt: niemals Aufruf: C Vertrauen: uneingeschr?nkt G?ltigkeit: uneingeschr?nkt sub 2048D/A916DB9A erzeugt: 2014-11-30 verf?llt: niemals Aufruf: S sub 3072R/599E4462 erzeugt: 2014-11-30 verf?llt: niemals Aufruf: E [ uneing.] (1). rsa3072 name (kom) Second attempt, editing: After test-editing the subkeys with changing DSA-subkey it gets last position and is not working in PGP-6.5.x pub 3072R/D956D57E erzeugt: 2014-11-30 verf?llt: niemals Aufruf: C Vertrauen: uneingeschr?nkt G?ltigkeit: uneingeschr?nkt sub 3072R/599E4462 erzeugt: 2014-11-30 verf?llt: niemals Aufruf: E sub 2048D/01D27D06 erzeugt: 2014-11-30 verf?llt: niemals Aufruf: S [ uneing.] (1). rsa3072 name (kom) Third attempt, everything is working in PGP-6.5.x too, RSA only: pub 3072R/D956D57E erzeugt: 2014-11-30 verf?llt: niemals Aufruf: C Vertrauen: uneingeschr?nkt G?ltigkeit: uneingeschr?nkt sub 3072R/599E4462 erzeugt: 2014-11-30 verf?llt: niemals Aufruf: E sub 3072R/B65BF3EE erzeugt: 2014-11-30 verf?llt: niemals Aufruf: S [ uneing.] (1). rsa3072 name (kom) No difference, if using RSA-2048 bit. No Difference, if using DSA-1024 bit. If new keypair is created 'by hand' in this order: RSA C 3072 DSA S 2048 RSA E 3072 everything works till editing any of subkey. But this option is needed because of future changings in subkey set while keeping main key ID... So, is there a known issue regarding the order of DSA-subkeys for signing? How to change order of subkeys for testing purpose? Thanks and best regards, Chris From rjh at sixdemonbag.org Sun Nov 30 21:07:09 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Nov 2014 15:07:09 -0500 Subject: Order/changing of subkeys derogates compatibility!? In-Reply-To: <7B3B0E.547B7C39.0002@gate> References: <7B3B0E.547B7C39.0002@gate> Message-ID: <547B78ED.5070603@sixdemonbag.org> > while creating some new v4-RSA keypairs a compatibility issue occurs with > old PGP-6.5.x: 6.5.8 is about sixteen years old now and has many known security problems. Please stop using it. From rjh at sixdemonbag.org Sun Nov 30 23:49:32 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 30 Nov 2014 17:49:32 -0500 Subject: Difference Kleopatra vs WinPT In-Reply-To: <695838.99198.bm@smtp105.mail.ir2.yahoo.com> References: <695838.99198.bm@smtp105.mail.ir2.yahoo.com> Message-ID: <547B9EFC.3060108@sixdemonbag.org> > Which one is better/more used? WinPT only works with the 1.4 branch of GnuPG and hasn't had a new release in the last five years. I'm under the impression Timo (the author) has stopped working on it or supporting it. Given that, I'd have to recommend not using WinPT.