From aaron.toponce at gmail.com Sun Jul 1 15:49:55 2012 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Sun, 1 Jul 2012 07:49:55 -0600 Subject: ideal.dll // fixing thread breaking In-Reply-To: <4FEDE9AD.1020306@sixdemonbag.org> References: <4FEB27D7.80902@digitalbrains.com> <4FEC3492.7000405@hotmail.com> <4FEC4585.20002@digitalbrains.com> <4FEC7730.2030004@hotmail.com> <4FECA764.1050301@digitalbrains.com> <4FED59BD.5070703@hotmail.com> <20120629130620.7e1df026@abydos.stargate.org.uk> <4FEDCE4C.3060903@sixdemonbag.org> <20120629172643.2f01185d@abydos.stargate.org.uk> <4FEDE9AD.1020306@sixdemonbag.org> Message-ID: <20120701134953.GY10597@pinyin.ae7.st> On Fri, Jun 29, 2012 at 01:45:17PM -0400, Robert J. Hansen wrote: > IMO, if your client is showing correct PGP/MIME signatures on this list, > you should file a defect report about your client. The message has been > changed in transit and is no longer in the exact same state as it was > when the sender issued it. The change may be trivial, but it's still a > change, and IMO it is not the job of the MUA to try and fix the botchery > inflicted by GNU Mailman. The correct thing to do, IMO, is to report to > the user the true state of affairs: "the signature is not correct and > the message appears to have been altered in transit." I don't understand this. Mutt verifies the signature correctly, but Mutt is calling GnuPG externally. If the message was signed with a space, and if the space is being replaced by a tab character, then the signature should fail. Because it is not failing, is telling me that it was initially a tab when you signed the mail, and something either mangled it to be a space, or your diff(1) is reading a text that mangled the tab to a space. I don't see how this is the failure of the MUA, but GnuPG says the signature verifies. -- . 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: 519 bytes Desc: not available URL: From mancha at mac.hush.com Wed Jul 4 12:54:18 2012 From: mancha at mac.hush.com (mancha at mac.hush.com) Date: Wed, 04 Jul 2012 05:54:18 -0500 Subject: Preference de-sync between public & private keys Message-ID: <20120704105418.8A2B214DBDE@smtp.hushmail.com> Hi. I recently encountered interesting (buggy?) behavior in the way gpg deals with the preference order of key pairs. If one sets a default preference order in gpg.conf like so: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES CAST5 AES192 ZLIB BZIP2 ZIP Uncompressed and generates a key-pair and exports each: $ gpg --export -a "temporary" > temp-pub.asc $ gpg --export-secret-key -a "temporary" > temp-pri.asc the preference order coincides between public & private: $ gpg --list-packets temp-pub.asc [snip] pref-sym-algos: 9 7 3 8 [snip] $ gpg --list-packets temp-pri.asc [snip] pref-sym-algos: 9 7 3 8 [snip] Now, if we change gpg.conf to have aes128 first in the cipher list: default-preference-list SHA512 SHA384 SHA256 SHA224 AES CAST5 AES192 AES256 ZLIB BZIP2 ZIP Uncompressed And change the prefs via --edit-key -> updpref/setpref, only the public key gets changed. Private and public keys no longer coincide. $ gpg --list-packets temp-pub.asc [snip] pref-sym-algos: 7 3 8 9 [snip] $ gpg --list-packets temp-pri.asc [snip] pref-sym-algos: 9 7 3 8 [snip] Thanks in advance for your time. From mailinglisten at hauke-laging.de Fri Jul 6 21:05:55 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 06 Jul 2012 21:05:55 +0200 Subject: Documentation error: --allow-freeform-uid not needed? Message-ID: <3059210.PbFFF1CdVA@inno> Hello, I just noticed that it is possible to create UIDs without an email address without giving the option --allow-freeform-uid. The man page says: --allow-freeform-uid Disable all checks on the form of the user ID while generating a new one. This option should only be used in very special environments as it does not ensure the de-facto standard format of user IDs. Google did not solve my confusion. This seems not to be related to --expert (I tried with --options /dev/null) Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From expires2012 at rocketmail.com Sun Jul 8 16:15:20 2012 From: expires2012 at rocketmail.com (MFPA) Date: Sun, 8 Jul 2012 15:15:20 +0100 Subject: Documentation error: --allow-freeform-uid not needed? In-Reply-To: <3059210.PbFFF1CdVA@inno> References: <3059210.PbFFF1CdVA@inno> Message-ID: <1789383756.20120708151520@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 6 July 2012 at 8:05:55 PM, in , Hauke Laging wrote: > I just noticed that it is possible to create UIDs > without an email address without giving the option > --allow-freeform-uid. [snipped] > This seems not to be > related to --expert (I tried with --options /dev/null) I just found the same, using GnuPG v1.4.12 under Windows XP. I was able to create a key with a string of letters for "real name" and just hitting for the "email address" and "comment" prompts. (On Windows, it seems to be "nul" rather than "null" but I also tried --no-options, and I tried actually pointing to an empty gpg-conf file just to be sure.) - -- Best regards MFPA mailto:expires2012 at rocketmail.com You're only young once; you can be immature forever -----BEGIN PGP SIGNATURE----- iQCVAwUBT/mV/qipC46tDG5pAQrxxgQAoc7o9VE34MVRa/8SEZi6UvSmD95zm2m+ gESuokY8kKdGNG1vWNd4ME/Z4vrS/D6l8dfiprxxC+pih0yElh8e58K2vTXp1k1r pAfMbABwxL/ZLH17vYC0Z+8ve2GGrixzJRHp56f2a/b2qJfSTK800j75ENRIaZ8D naUjyCikcW4= =GkRp -----END PGP SIGNATURE----- From wk at gnupg.org Mon Jul 9 09:57:42 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Jul 2012 09:57:42 +0200 Subject: Documentation error: --allow-freeform-uid not needed? In-Reply-To: <3059210.PbFFF1CdVA@inno> (Hauke Laging's message of "Fri, 06 Jul 2012 21:05:55 +0200") References: <3059210.PbFFF1CdVA@inno> Message-ID: <87k3ydqscp.fsf@vigenere.g10code.de> On Fri, 6 Jul 2012 21:05, mailinglisten at hauke-laging.de said: > I just noticed that it is possible to create UIDs without an email address > without giving the option --allow-freeform-uid. The man page says: That is perfectly okay. Not every user has a mail address. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Mon Jul 9 14:26:38 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 09 Jul 2012 14:26:38 +0200 Subject: Documentation error: --allow-freeform-uid not needed? In-Reply-To: <87k3ydqscp.fsf@vigenere.g10code.de> References: <3059210.PbFFF1CdVA@inno> <87k3ydqscp.fsf@vigenere.g10code.de> Message-ID: <1492472.q8pmTEKgax@inno> Am Mo 09.07.2012, 09:57:42 schrieb Werner Koch: > On Fri, 6 Jul 2012 21:05, mailinglisten at hauke-laging.de said: > > I just noticed that it is possible to create UIDs without an email > > address > > without giving the option --allow-freeform-uid. The man page says: > That is perfectly okay. Not every user has a mail address. OK but what does --allow-freeform-uid do then? Makses sense to add this information to the documentation IMHO. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From ml-gpg at m-privacy.de Mon Jul 9 12:34:54 2012 From: ml-gpg at m-privacy.de (Roman) Date: Mon, 09 Jul 2012 12:34:54 +0200 Subject: Can GPG make use of OAEP form new LibGCrypt 1.5.0? Message-ID: <4FFAB3CE.4060900@m-privacy.de> Hello list, I read that Libgcrypt 1.5.0 has support for OAEP and PSS methods as described by RFC-3447. Does GnuPG 2.0.19 make use of this libgcrypt? And is there any flag, environment variable or command-line option that could be passed to gpg2, to make it use RSA-OAEP padding for encryption? Thanx a lot! Roman -- m-privacy GmbH Am K?llnischen Park 1 10179 Berlin Fon: +49 30 24342334 Fax: +49 30 99296856 http://www.m-privacy.de GnuPG-Key-ID: 0x2DD3A649 From toothache200873 at yahoo.com Mon Jul 9 18:19:56 2012 From: toothache200873 at yahoo.com (Condor Kim) Date: Mon, 9 Jul 2012 09:19:56 -0700 (PDT) Subject: No subject Message-ID: <1341850796.27654.YahooMailNeo@web46114.mail.sp1.yahoo.com> http://placadepar.org/wp-admin/mnews.php?north220.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jul 9 19:12:41 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Jul 2012 19:12:41 +0200 Subject: Can GPG make use of OAEP form new LibGCrypt 1.5.0? In-Reply-To: <4FFAB3CE.4060900@m-privacy.de> (Roman's message of "Mon, 09 Jul 2012 12:34:54 +0200") References: <4FFAB3CE.4060900@m-privacy.de> Message-ID: <878vesrh86.fsf@vigenere.g10code.de> On Mon, 9 Jul 2012 12:34, ml-gpg at m-privacy.de said: > And is there any flag, environment variable or command-line option that > could be passed to gpg2, to make it use RSA-OAEP padding for encryption? OpenPGP does not define OAEP thus we can't use it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smickson at hotmail.com Mon Jul 9 23:45:37 2012 From: smickson at hotmail.com (Sam Smith) Date: Mon, 9 Jul 2012 17:45:37 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? Message-ID: Here's the result of ShowPRef for my key: Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA256, SHA1, SHA384, SHA512, SHA224 Compression: ZLIB, BZIP2, ZIP, Uncompressed SHA1 is showing up second. So when I sign a message, why isn't SHA256 used? The headers on my emails appear to show SHA1 as the hash being used. I no longer consider SHA1 secure. Neither does the U.S. Government. So I don't want it to be the default hash being used. How do I get SHA256 to be the default hash used when I sign emails and encrypt them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Mon Jul 9 23:56:11 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 09 Jul 2012 23:56:11 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: <1691085.zBBYnp7yOC@inno> Am Mo 09.07.2012, 17:45:37 schrieb Sam Smith: > Here's the result of ShowPRef for my key: > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA256, SHA1, SHA384, SHA512, SHA224 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > > SHA1 is showing up second. So when I sign a message, why isn't SHA256 used? Your key tells others what to do. For what you do yourself ("when I sign a message") you have to edit the config file. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From laurent.jumet at skynet.be Tue Jul 10 00:18:09 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Tue, 10 Jul 2012 00:18:09 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: Message-ID: Hello Sam ! Sam Smith wrote: > Here's the result of ShowPRef for my key: > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA256, SHA1, SHA384, SHA512, SHA224 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > SHA1 is showing up second. So when I sign a message, why isn't SHA256 used? > The headers on my emails appear to show SHA1 as the hash being used. > I no longer consider SHA1 secure. Neither does the U.S. Government. So I > don't want it to be the default hash being used. > How do I get SHA256 to be the default hash used when I sign emails and > encrypt them? I think that by default, --gnupg is in use; --gnupg means --openpgp This means strict OpenPGP behaviour: MD5, SHA1, RIPEMD160 Try using "--digest-algo SHA256" in the command line or GPG.CONF; may be you'll need to suppress "--personal-digest-preferences" from GPG.CONF (I don't know). -- Laurent Jumet KeyID: 0xCFAF704C From mailinglisten at hauke-laging.de Tue Jul 10 00:53:43 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Jul 2012 00:53:43 +0200 Subject: Slightly OT: PGP/MIME verification fails with new KMail2 and Thunderbird 13.0 Message-ID: <4094277.JZxR0HK2IT@inno> Hello, I was just pointed at the problem that for the last months all of my signatures are supposed to be bad. I use KMail which shows both the emails I have sent and those I receive via this list as correctly signed. I just used Thunderbird (13.0) to check and TB claims even (most but not all) of the emails in my IMAP sent folder to have bad signatures. TB doesn't even recognize the received emails as signed (just shows an "attachment"). The problem seems to be newline-related. I do not waste time by filing a bug report for the wrong software... Thus maybe one of the MIME experts here can tell me who's wrong. The KMail behaviour seems to have changed from KMail to KMail2. KMail2 successfully verifies the TB emails. Thunderbird puts one more empty line between the body and the MIME seperator: ####################################### PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 --nextPart1869494.a4NpQxFzAE Content-Type: application/pgp-signature; name="signature.asc" ####################################### ####################################### PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 --------------enigDCF37498B4DFB4B1B81B232B Content-Type: application/pgp-signature; name="signature.asc" ####################################### I can manually successfully verify emails from both clients. So obviously one of them feeds the wrong data into gpg (during signing or verification). Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Tue Jul 10 01:12:28 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Jul 2012 19:12:28 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: <4FFB655C.4030200@sixdemonbag.org> On 07/09/2012 06:18 PM, Laurent Jumet wrote: > I think that by default, --gnupg is in use; --gnupg means --openpgp > This means strict OpenPGP behaviour: MD5, SHA1, RIPEMD160 Nope. > Try using "--digest-algo SHA256" in the command line or GPG.CONF; > may be you'll need to suppress "--personal-digest-preferences" from > GPG.CONF (I don't know). I feel like I've said this several times in the past few months. Let me say it one more time, loudly: DON'T USE --cipher-algo OR --digest-algo UNLESS YOU KNOW EXACTLY WHAT YOU'RE DOING AND WHY. IT'S EASY TO CREATE MESSAGES YOUR RECIPIENT CANNOT READ. USE THE --personal-X-preferences INSTEAD. I feel like I ought apologize for shouting, but really, this has been said so many times in the last couple of months that I'm getting really frustrated with correcting the "oh, just use --X-algo!" misadvice that gets handed out so often. From vedaal.nistar at gmail.com Tue Jul 10 04:04:21 2012 From: vedaal.nistar at gmail.com (vedaal) Date: Mon, 09 Jul 2012 22:04:21 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFB655C.4030200@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> Message-ID: <4FFB8DA5.4070203@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/9/2012 7:12 PM, Robert J. Hansen wrote: > DON'T USE --cipher-algo OR --digest-algo UNLESS YOU KNOW EXACTLY WHAT YOU'RE DOING AND WHY. IT'S EASY TO CREATE MESSAGES YOUR RECIPIENT CANNOT READ. which open-pgp implementation can't read/verify SHA-256 (btw, am trying out thunderbird with enigmail, and a new gmail account, to try to not 'break threads' please let me know if it still breaks, thanks, vedaal my keys: http://www.angelfire.com/pr/pgpf/mykeys.html (have not yet added the new gmail uid and uploaded to keyservers) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Acts of Kindness better the World, and protect the Soul Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP+42lAAoJEFBvT6HTX7GG1asP/R2dpIJTBdOVkvgZVpF5Lhqp PcK6+nou2H9MYwbv99R9VGzVqvJqm+vURAe7vbHaYJGjzi8CEitoHTotPh3FNxfG DHbXkKhH8zW3k2ubxwOPyf1eeIaYJXX+GJHK6AFGGkU4iqmKW9481kUBoJmNg67H SQbZAi9d5ZnqLl7/oBviRp6crT6EIw5F5Lb4yMlR0EDikuWyLa6kS1zbOIMwEco0 8lipwtoTf5vP+hwdGIWb0xo5tdNLD5iNn1KTHN0kCsLCUc3ybNfqtlV/mDBg3yrv xTSMKdMKkoBzey9Vn0nfIZa3QwJ+u6NWSwNTwAaWc/IdWsn3JpbdbTruLYvEJo+X cgqzqjP8t4Wpcz7GnPqWjsAEOfqH4J2ocfd8DLzasxW8l6rinN3tnj7bnd6g+XhY KzxeFNaHEMUIKlOpaYAPxKdu6GLvRom2QR8VDHhlwUhxTphVtgUmCNDuAWfyRh2l WfWzvZ0xjDI8r6wMdR75Ud4pDVMs7jIE8ncX3a8BI018nRamTCyqwPvvpa1BrbCF JrH+0yf3/4nCUW4dgarzdPkgTJzRRKsJ348Uy9mEjRtyM4sDBloETcQsn0KDx68n CV0cXUxANTuQZhrNzJyiTrJU9UR+ueaBdOIMIDrnivoYsp1qT5K/mYcvbyzqyIC9 0Bz4N71sL9FBePE8jEi8 =zLDr -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Jul 10 05:10:27 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Jul 2012 23:10:27 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFB8DA5.4070203@gmail.com> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> Message-ID: <4FFB9D23.3020209@sixdemonbag.org> On 7/9/2012 10:04 PM, vedaal wrote: > which open-pgp implementation can't read/verify SHA-256 PGP 8.0 or before. SHA-256 was introduced in 8.1, if I recall correctly. There are still a *lot* of people using 6.5.8. From laurent.jumet at skynet.be Tue Jul 10 07:59:56 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Tue, 10 Jul 2012 07:59:56 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFB655C.4030200@sixdemonbag.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello Robert ! "Robert J. Hansen" wrote: >> I think that by default, --gnupg is in use; --gnupg means --openpgp >> This means strict OpenPGP behaviour: MD5, SHA1, RIPEMD160 > Nope. >> Try using "--digest-algo SHA256" in the command line or GPG.CONF; >> may be you'll need to suppress "--personal-digest-preferences" from >> GPG.CONF (I don't know). > I feel like I've said this several times in the past few months. Let me > say it one more time, loudly: > DON'T USE --cipher-algo OR --digest-algo UNLESS YOU KNOW EXACTLY WHAT > YOU'RE DOING AND WHY. IT'S EASY TO CREATE MESSAGES YOUR RECIPIENT > CANNOT READ. USE THE --personal-X-preferences INSTEAD. The question was: why does GPG uses another preference that the primary one? I've the same problem, this ClearSign message is in RIPEMD160 despite it's not the first choice, and obviously there is no receipient here. - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) iHEEAREDADEFAk/7xaYqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMvUMAoJo9kNtbXW39GOHMSmB8EMaDHu9DAKCw q2MNfcNyx5aLv/titlDxloqy2g== =1mFk -----END PGP SIGNATURE----- From branko at majic.rs Tue Jul 10 08:43:55 2012 From: branko at majic.rs (Branko Majic) Date: Tue, 10 Jul 2012 08:43:55 +0200 Subject: Slightly OT: PGP/MIME verification fails with new KMail2 and Thunderbird 13.0 In-Reply-To: <4094277.JZxR0HK2IT@inno> References: <4094277.JZxR0HK2IT@inno> Message-ID: <20120710084355.5fda8c40@zetkin.int.primekey.se> As a curiosity, could you have both clients save the message in raw format somewhere on the disks, and compare if they're the same with a checksum? Maybe there's some misbehavior with the line endings in terms of *nix vs Winblow$ (so checking with cat -v would also be a good idea)? I know that at some point I managed to corrupt an Apache configuration file by copy/pasting stuff from KMail into terminal (but that was very long time ago), there were some "invibisble" characters pasted in the process. On Tue, 10 Jul 2012 00:53:43 +0200 Hauke Laging wrote: > Hello, > > I was just pointed at the problem that for the last months all of my > signatures are supposed to be bad. I use KMail which shows both the > emails I have sent and those I receive via this list as correctly > signed. I just used Thunderbird (13.0) to check and TB claims even > (most but not all) of the emails in my IMAP sent folder to have bad > signatures. TB doesn't even recognize the received emails as signed > (just shows an "attachment"). > > The problem seems to be newline-related. I do not waste time by > filing a bug report for the wrong software... Thus maybe one of the > MIME experts here can tell me who's wrong. The KMail behaviour seems > to have changed from KMail to KMail2. KMail2 successfully verifies > the TB emails. > > Thunderbird puts one more empty line between the body and the MIME > seperator: > > ####################################### > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 > > --nextPart1869494.a4NpQxFzAE > Content-Type: application/pgp-signature; name="signature.asc" > ####################################### > > ####################################### > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 > > > --------------enigDCF37498B4DFB4B1B81B232B > Content-Type: application/pgp-signature; name="signature.asc" > ####################################### > > I can manually successfully verify emails from both clients. So > obviously one of them feeds the wrong data into gpg (during signing > or verification). > > > Hauke -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. From wk at gnupg.org Tue Jul 10 10:53:37 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Jul 2012 10:53:37 +0200 Subject: Documentation error: --allow-freeform-uid not needed? In-Reply-To: <1492472.q8pmTEKgax@inno> (Hauke Laging's message of "Mon, 09 Jul 2012 14:26:38 +0200") References: <3059210.PbFFF1CdVA@inno> <87k3ydqscp.fsf@vigenere.g10code.de> <1492472.q8pmTEKgax@inno> Message-ID: <87k3ycov3i.fsf@vigenere.g10code.de> On Mon, 9 Jul 2012 14:26, mailinglisten at hauke-laging.de said: > OK but what does --allow-freeform-uid do then? Makses sense to add this You already quoted it in your first mail: Disable all checks on the form of the user ID w...... ^^^^^ Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dougb at dougbarton.us Tue Jul 10 10:58:07 2012 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 10 Jul 2012 01:58:07 -0700 (PDT) Subject: Slightly OT: PGP/MIME verification fails with new KMail2 and Thunderbird 13.0 In-Reply-To: <4094277.JZxR0HK2IT@inno> References: <4094277.JZxR0HK2IT@inno> Message-ID: On Tue, 10 Jul 2012, Hauke Laging wrote: > Hello, > > I was just pointed at the problem that for the last months all of my > signatures are supposed to be bad. I use KMail which shows both the emails I > have sent and those I receive via this list as correctly signed. I just used > Thunderbird (13.0) to check and TB claims even (most but not all) of the > emails in my IMAP sent folder to have bad signatures. TB doesn't even > recognize the received emails as signed (just shows an "attachment"). > > The problem seems to be newline-related. I do not waste time by filing a bug > report for the wrong software... Thus maybe one of the MIME experts here can > tell me who's wrong. The KMail behaviour seems to have changed from KMail to > KMail2. KMail2 successfully verifies the TB emails. There is a difference in how KMail deals with EOL whitespace, I have an exception for it in my PGP filters for Alpine. I don't know what's different between KMail 1 and 2, but I'm glad you raised this. I can use my filters to verify your KMail 1.x messages, but Enigmail refuses to recognize that they contain valid signed messages. However I cannot verify your latest message using KMail 2, so clearly there is something different. > Thunderbird puts one more empty line between the body and the MIME seperator: I'm not sure it's Thunderbird, I think it's Mailman (at least that was the consensus from previous discussion). Have you compared the raw message in your Sent mail folder to the one from the list? Also, if you look at your message in the archives, it seems to be similarly malformed. > I can manually successfully verify emails from both clients. So obviously one > of them feeds the wrong data into gpg (during signing or verification). Don't rule out "all of the above." :) Seriously though, can you do me a favor and send me copies of the _raw_ messages from your Sent mail folder, and the message you received from the list (the one I'm responding to is fine)? Please compress them somehow (tgz is fine) so that they don't get molested in transit. That'll help me sort out how whitespace is being handled differently in KMail 2. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From rjh at sixdemonbag.org Tue Jul 10 11:02:34 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jul 2012 05:02:34 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: <4FFBEFAA.1040800@sixdemonbag.org> On 7/10/2012 1:59 AM, Laurent Jumet wrote: > The question was: why does GPG uses another preference that the primary > one? The short answer is, "because it has to, and because you've configured it that way." > I've the same problem, this ClearSign message is in RIPEMD160 despite it's > not the first choice, and obviously there is no receipient here. What are the contents of your personal-digest-preferences? Also note that you're using a 1k DSA key for signing, so is it really so surprising you're using a 160-bit hash algorithm? From andy.ruddock at rainydayz.org Tue Jul 10 10:58:52 2012 From: andy.ruddock at rainydayz.org (Andy Ruddock) Date: Tue, 10 Jul 2012 09:58:52 +0100 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFB9D23.3020209@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> Message-ID: <4FFBEECC.6020309@rainydayz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Robert J. Hansen wrote: > On 7/9/2012 10:04 PM, vedaal wrote: >> which open-pgp implementation can't read/verify SHA-256 > > PGP 8.0 or before. SHA-256 was introduced in 8.1, if I recall > correctly. There are still a *lot* of people using 6.5.8. > I used the information in this article : http://www.debian-administration.org/users/dkg/weblog/48 If there are errors or omissions I'd be interested to learn, as the article is now over 3 years old. - -- Andy Ruddock - ------------ andy.ruddock at rainydayz.org (GPG Key ID 0xB0324245) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJP++7MAAoJECqtbbewMkJFUikQAIqZvd1GpSwLxzhkFiaVyt5J igyqJeC/ad2ZVdrAhL+39LHnpeh4hrmpHriDH9bamHzEGS46Z3YH2OyN4eRdszOc 0WHrWTRL+ZmswR9zz5RdCpBb9OgHJ7IXhP5xvrLFu13yqCc1HdF3RgLijH8E4JMv 7FttDIFrllf0dOW6X3ZFXbVazsvvc1QzILc4Io76pAZq/KuS7Snr/nTVMts3MpvL YUy7UeqzSTAkqIFAvgRmP6rfd+gVXeJiUc2hio/2cD+/0mzAwrnfsbipRsjvkYNi 3Irzd4qaIoqi5LOlQ6f0wFGoiuqQPKSlr74TApvv4PEBDoziVzqywI8tlNx1keeS gUsD1BV2Q1I+gm/skOoIIqYvXVV8aMouey6OZ6Dtzw1QH4UJOe2F7kx60pvyDpQe tllRdxsxrHmoHXLrNOYoY7Ncpia8soEUkvIX8ZVG40PNhIPxRlFTD8tWJSt+YNe1 X9OaVWUiIA3QveDPszeyfXlQwTK0dlUfJB0zZI16kTaSpPn1wIYaX2q8sKYgFtfA 0UAGCpkGCfMa2eDE5RILyNEYj6d1eKJ8kCGwyQKLu6O3ck8rfEAx29W1sMa6n/D4 JdEqOl8CoVF5LhRFtzfO85gKLaotv1vsfCAsZfC8R+w8dhQZN9pdrHp3KmykrQM9 LunQ9W3QGT1CnVDcawnX =kBZf -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Jul 10 11:19:45 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jul 2012 05:19:45 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFBEECC.6020309@rainydayz.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFBEECC.6020309@rainydayz.org> Message-ID: <4FFBF3B1.5060003@sixdemonbag.org> On 7/10/2012 4:58 AM, Andy Ruddock wrote: > I used the information in this article : It is still substantially accurate and useful, as near as I can tell. (I still think cert-digest-algo sha256 is unnecessary at this point in time, but I understand why he believes otherwise, and his perspective is hardly an unreasoned one.) From andy.ruddock at rainydayz.org Tue Jul 10 11:24:42 2012 From: andy.ruddock at rainydayz.org (Andy Ruddock) Date: Tue, 10 Jul 2012 10:24:42 +0100 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFBF3B1.5060003@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFBEECC.6020309@rainydayz.org> <4FFBF3B1.5060003@sixdemonbag.org> Message-ID: <4FFBF4DA.6060800@rainydayz.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Robert J. Hansen wrote: > On 7/10/2012 4:58 AM, Andy Ruddock wrote: >> I used the information in this article : > > It is still substantially accurate and useful, as near as I can tell. > (I still think cert-digest-algo sha256 is unnecessary at this point in > time, but I understand why he believes otherwise, and his perspective is > hardly an unreasoned one.) Good to hear it, thank you. Crypto is one of those areas where it is easy to make a mess of things, so I think it's best to leave it to the experts. The problem then, of course, is determining who can be judged expert. - -- Andy Ruddock - ------------ andy.ruddock at rainydayz.org (GPG Key ID 0xB0324245) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJP+/TaAAoJECqtbbewMkJFIq0QAIR5MzIx7my7726PeN1l1Rff Ut1EFvj4xtLLfa2ilplpMCh+KsMIEAjBNxPHIZGRjaIUbuY8Gi6PN1eXF8IVoWr3 5BakwSwPW52+3I8BjRXWy0G1IT4NDfYyeSn/prXUisNsRFeR3XxYwGwlqME8cmeo e6LUs1tIT/cskadLRJ003ymTPXFwTB3UdSXMN+Pi2BkAo5kJE6gJTFezsOyP1Eub rau/IijrVT8BHP1p/DstHnc1SkZJS148qXfwBYvJEy/yrU2x7YZHQTnIlISxKn2M DhFSf6UNrxyB4V7mFnMchDAIFshXQrQ/lkdj0v4wHoREWArP15JhMsjgJaAE4NqN 3Yffa5SC3GSAZWL5A42/LQIKKP13akbNqGwH40tygcjmG4YxDs3JlrBD0VnQNLGH jYTtZfT7TyYlJDaTGl3BbHF498y6Imu4TNTZqiWZH5c8Ue3yFi/feD2r1GH98yAG I47e+iaiwhmh40Iu/BJhXlR+F54dKmcIPj8U1Ip2ywO/6x6fWkI56XrRQp4/BFSb HPZBu2Bg+3KCesIKyeb5Tv3m1qU7Is7YggeoMhIAo0U0COY37AewBGh7CkDzayKi rCwTZDv+3HPNPkNjYHxnTyJtUhpOVewgswI8VrW3kUGDlS3RcceP/0Rr4USvbnk5 +F420yI/keYGepSBWzzC =acaH -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Tue Jul 10 14:23:11 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Jul 2012 14:23:11 +0200 Subject: Slightly OT: PGP/MIME verification fails with new KMail2 and Thunderbird 13.0 In-Reply-To: <20120710084355.5fda8c40@zetkin.int.primekey.se> References: <4094277.JZxR0HK2IT@inno> <20120710084355.5fda8c40@zetkin.int.primekey.se> Message-ID: <1912049.dXTSNZoDiO@inno> Am Di 10.07.2012, 08:43:55 schrieb Branko Majic: > As a curiosity, could you have both clients save the message in raw > format somewhere on the disks, and compare if they're the same with a > checksum? A checksum is not neccessary, it's obviously not the same. KMail stores the files with \n line endings instead of \r\n. In order to successfully verify the signature I had to convert the KMail file to \r\n and to remove the \r\n (both) on the last line until I added a \n to my text signature. ... I just checked the files after the conversion to \r\n. There were more differences (probably not relevant for this problem). The KMail file has an addidional line at the beginning: >From hauke at laging.de Mon, 09 Jul 2012 20:06:34 +0200 Furthermore the KMail file has \r\n at the end of the last line, the TB file does not. But the signed part and the signature are stored identically. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From smickson at hotmail.com Tue Jul 10 14:26:14 2012 From: smickson at hotmail.com (Sam Smith) Date: Tue, 10 Jul 2012 08:26:14 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <1691085.zBBYnp7yOC@inno> References: , <1691085.zBBYnp7yOC@inno> Message-ID: Hauke, thank you so much for explaining this. Would you be so kind as to describe how exactly I should edit my config file to accomplish SHA256? There's lots of "advice" out there and I'd like to make sure I don't make any mistakes when configuring. Thank you. From: mailinglisten at hauke-laging.de To: gnupg-users at gnupg.org Subject: Re: why is SHA1 used? How do I get SHA256 to be used? Date: Mon, 9 Jul 2012 23:56:11 +0200 Am Mo 09.07.2012, 17:45:37 schrieb Sam Smith: > Here's the result of ShowPRef for my key: > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA256, SHA1, SHA384, SHA512, SHA224 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > > SHA1 is showing up second. So when I sign a message, why isn't SHA256 used? Your key tells others what to do. For what you do yourself ("when I sign a message") you have to edit the config file. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 _______________________________________________ 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 smickson at hotmail.com Tue Jul 10 14:42:04 2012 From: smickson at hotmail.com (Sam Smith) Date: Tue, 10 Jul 2012 08:42:04 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFB9D23.3020209@sixdemonbag.org> References: , <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com>,<4FFB9D23.3020209@sixdemonbag.org> Message-ID: Yeah, there's still people on Internet Explorer 6 & 7 too and they cause all kinds of problems for web developers. If people using really old versions can't read something, that's really their burden to update their software. SHA1 is no longer secure. I'm not going to cater to people using really old versions, especially when security is involved. > Date: Mon, 9 Jul 2012 23:10:27 -0400 > From: rjh at sixdemonbag.org > To: gnupg-users at gnupg.org > Subject: Re: why is SHA1 used? How do I get SHA256 to be used? > > On 7/9/2012 10:04 PM, vedaal wrote: > > which open-pgp implementation can't read/verify SHA-256 > > PGP 8.0 or before. SHA-256 was introduced in 8.1, if I recall > correctly. There are still a *lot* of people using 6.5.8. > > _______________________________________________ > 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 Tue Jul 10 16:10:12 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jul 2012 10:10:12 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: , <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com>, <4FFB9D23.3020209@sixdemonbag.org> Message-ID: <4FFC37C4.60303@sixdemonbag.org> > SHA1 is no longer secure. At the present moment, SHA-1 is just fine. In the fairly near future, anywhere between six months to a few years, I expect this will change. But "SHA1 is no longer secure" is factually untrue, at least where OpenPGP is concerned. I don't recommend SHA-1 for new signatures, but if you have a choice between sending a SHA-1 message which your recipient can verify or a SHA-256 message which your recipient can't, well -- that math's pretty easy to do. SHA-1 isn't a good choice for new signatures, but it's a lot better than no signature. > I'm not going to cater to people using really old versions, > especially when security is involved. The good news is that no one's asking you to. You're only being advised, "don't use --digest-algo SHA256, it's unwise and can break interoperability. Use --personal-digest-preferences SHA256 instead." This is the same advice that has been given by the GnuPG developers, by the Enigmail team, and by many other people within the community. It's a best-practices thing for GnuPG. Don't use --digest-algo. Use --personal-digest-preferences. That's all. From mailinglisten at hauke-laging.de Tue Jul 10 16:19:18 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Jul 2012 16:19:18 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: <1691085.zBBYnp7yOC@inno> Message-ID: <4991784.Qb0HQuFMA3@inno> Am Di 10.07.2012, 08:26:14 schrieb Sam Smith: > Hauke, thank you so much for explaining this. Would you be so kind as to > describe how exactly I should edit my config file to accomplish SHA256? As Rob already mentioned: You need --personal-digest-preferences (which is just personal-digest-preferences in the config file). You put your favourite first, e.g.: personal-digest-preferences SHA256,RIPEMD160,SHA1 Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From laurent.jumet at skynet.be Tue Jul 10 16:39:20 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Tue, 10 Jul 2012 16:39:20 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4991784.Qb0HQuFMA3@inno> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello Hauke ! Hauke Laging wrote: > As Rob already mentioned: You need --personal-digest-preferences (which is > just personal-digest-preferences in the config file). You put your favourite > first, e.g.: > personal-digest-preferences SHA256,RIPEMD160,SHA1 Do you succeed in having a SHA256 hash with this statement? How can I explain that I have RIPEMD160 instead? - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) iHEEAREDADEFAk/8PwwqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMRUgAnAli775gSYM8jzLws2QUIzFWs1OUAJ4v +nb4d0H7K5EsWQ7Vu9Hv9/r3mQ== =63v/ -----END PGP SIGNATURE----- From peter at digitalbrains.com Tue Jul 10 17:03:21 2012 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 10 Jul 2012 17:03:21 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: <4FFC4439.6030109@digitalbrains.com> On 10/07/12 16:39, Laurent Jumet wrote: > Do you succeed in having a SHA256 hash with this statement? How can I > explain that I have RIPEMD160 instead? Like Rob said, > Also note that you're using a 1k DSA key for signing, so is it really so > surprising you're using a 160-bit hash algorithm? To truncate SHA-256 to fit in a 1k DSA signature, specify "--enable-dsa2". I personally don't use DSA, so there might be some more interesting options related to it. 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 http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt From mailinglisten at hauke-laging.de Tue Jul 10 17:15:55 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Jul 2012 17:15:55 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: <2787291.FEIyHRJDta@inno> Am Di 10.07.2012, 16:39:20 schrieb Laurent Jumet: > > personal-digest-preferences SHA256,RIPEMD160,SHA1 > > Do you succeed in having a SHA256 hash with this statement? Yes, I do. Just tried. > How can I explain that I have RIPEMD160 instead? Two possibilities come to my mind: 1) I created a signature using gpg only. Did you do that, too, or did you use some GUI or calling program (MUA)? 2) Are there conflicting statements in your config file? Maybe you can check by calling gpg --options /dev/null --personal-digest-preferences SHA256 --detach-sign... gpg --options /dev/null --personal-digest-preferences SHA256,RIPEMD160 ... Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Tue Jul 10 17:18:29 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 10 Jul 2012 11:18:29 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: On Jul 10, 2012, at 10:39 AM, Laurent Jumet wrote: > Hauke Laging wrote: > >> As Rob already mentioned: You need --personal-digest-preferences (which is >> just personal-digest-preferences in the config file). You put your favourite >> first, e.g.: > >> personal-digest-preferences SHA256,RIPEMD160,SHA1 > > Do you succeed in having a SHA256 hash with this statement? > How can I explain that I have RIPEMD160 instead? Your key is a 1024-bit DSA key. That key can only use a 160-bit hash, so you can use either RIPEMD160 or SHA-1. The rules for hash choice in DSA were relaxed a bit later, to allow for a 160-bit hash *or* a larger hash truncated to fit. To enable that, you can use "--enable-dsa2", and you should be able to get SHA256 - but note it's SHA256 truncated down to 160 bits. You can't use more than 160 bits without a larger DSA key. David From rjh at sixdemonbag.org Tue Jul 10 22:47:02 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jul 2012 16:47:02 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: References: Message-ID: <4FFC94C6.1020509@sixdemonbag.org> On 7/10/2012 10:39 AM, Laurent Jumet wrote: > Do you succeed in having a SHA256 hash with this statement? How can I > explain that I have RIPEMD160 instead? I apologize for repeating myself here: I don't mean to be condescending, but apparently my answer was not clear. I'll try to be more clear. You're using a DSA-1k key. It's limited to 160 bits. That means you cannot use SHA256. The best you can get is SHA256 truncated down to 160 bits, but at that point there's no difference between SHA256 and RIPEMD160. They both have the exact same margin of security: there are no known attacks against either. From boson at z1p.biz Tue Jul 10 21:22:11 2012 From: boson at z1p.biz (boson at z1p.biz) Date: Tue, 10 Jul 2012 21:22:11 +0200 Subject: keytocard: bad secret key Message-ID: <9a721f5c13af57da4f887a7f9e6518c4@mail.secure-mail.biz> I'm trying to save a 4096 bit RSA key to my OpenPGP smartcard v2.0 but I get an error about a "bad secret key". I use Ubuntu 10.04 with a self-compiled GnuPG 2.0.19 Verbose-mode doesn't tell more details and according to Google I am the only one with that problem... Does anyone know what's wrong? Regards ______________________________________________________ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. From mailinglisten at hauke-laging.de Wed Jul 11 01:22:42 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Jul 2012 01:22:42 +0200 Subject: very cautious :-) Message-ID: <5941084.tq991Cy71U@inno> gpg --options /dev/null --keyserver hkp://keys.gnupg.net --search-keys ... gpg: external program calls are disabled due to unsafe options file permissions -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From sandals at crustytoothpaste.net Wed Jul 11 01:59:45 2012 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Tue, 10 Jul 2012 23:59:45 +0000 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFC37C4.60303@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> Message-ID: <20120710235945.GC158060@crustytoothpaste.ath.cx> On Tue, Jul 10, 2012 at 10:10:12AM -0400, Robert J. Hansen wrote: > > SHA1 is no longer secure. > > At the present moment, SHA-1 is just fine. In the fairly near future, > anywhere between six months to a few years, I expect this will change. > But "SHA1 is no longer secure" is factually untrue, at least where > OpenPGP is concerned. SHA-1 is considered cryptographically broken. It does not provide the level of security it claims. Practically, collisions can be generated for 75 of the 80 rounds[0]. I hardly consider an algorithm this close to a collision "just fine". There's no need to run screaming to the exits, but a quick and orderly transition has been appropriate for some time. The time to move to something else is ending soon. > I don't recommend SHA-1 for new signatures, but if you have a choice > between sending a SHA-1 message which your recipient can verify > or a SHA-256 message which your recipient can't, well -- that math's > pretty easy to do. SHA-1 isn't a good choice for new signatures, but > it's a lot better than no signature. I don't generate signatures with algorithms I consider insecure because that leads to people being able to forge signatures in my name. If I use MD5, even for one message, that allows a moderately determined attacker to replay that signature on what is likely to become a fairly large set of messages. I'd rather avoid that, thank you. > > I'm not going to cater to people using really old versions, > > especially when security is involved. > > The good news is that no one's asking you to. You're only being > advised, "don't use --digest-algo SHA256, it's unwise and can break > interoperability. Use --personal-digest-preferences SHA256 instead." > This is the same advice that has been given by the GnuPG developers, by > the Enigmail team, and by many other people within the community. It's > a best-practices thing for GnuPG. The question is, will GnuPG fall back to SHA-1 if it's not in my digest preferences? I'd much rather fail to generate a signature than generate one using an algorithm which is very weak. [0] http://eprint.iacr.org/2011/641 -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Wed Jul 11 02:15:32 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jul 2012 20:15:32 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <20120710235945.GC158060@crustytoothpaste.ath.cx> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> Message-ID: <4FFCC5A4.8080708@sixdemonbag.org> On 7/10/2012 7:59 PM, brian m. carlson wrote: > SHA-1 is considered cryptographically broken. It does not provide > the level of security it claims. Yes. This is not the same as being *insecure*, though, which is what was claimed. Moving from "cryptographically broken" to "insecure/dead" is about as large a step as going from "nothing" to "cryptographically broken." MD5 was cryptographically broken in 1996. We didn't see major practical results against it until 2005 or so, and NIST didn't declare it to be dead and should no longer be used until 2010. There's some serious lag time there. SHA-1 will likely not have as long of a lag time, but let's not go about pretending there is no lag time or that the lag time has already elapsed. There tends to be a lot of scaremongering in the world of crypto. I think it's generally wise to be careful in our declarations. It is enough to say SHA-1 is known to not meet its design specifications and that some fairly devastating attacks against it will likely be coming along in the near future. That's already a good enough reason to reduce our usage of and dependency upon SHA-1. There's no need to fearmonger about how the algorithm has already collapsed, because it hasn't. > Practically, collisions can be generated for 75 of the 80 rounds[0]. Right now, only random collisions can be generated. That's not any use in forging a signature, which requires a preimage collision. A cryptographic break is not the same as a practical exploit. > I don't generate signatures with algorithms I consider insecure > because that leads to people being able to forge signatures in my > name. Then you need to stop using OpenPGP altogether, because you're already generating SHA-1 signatures with your certificate which can be lifted and dropped onto new messages if/when a preimage attack is introduced against SHA-1. Let me make this really clear: if you believe SHA-1 is insecure, you believe OpenPGP is insecure and you should stop using it. SHA-1 is hardwired into the OpenPGP spec in a few different places and, as of right now, cannot really be removed. The new V5 key format will almost certainly change this, but V5 won't be coming out for a good long while yet. > If I use MD5, even for one message, that allows a moderately > determined attacker to replay that signature on what is likely to > become a fairly large set of messages. I'd rather avoid that, thank > you. You've *already done this*. If you truly believe this, stop using OpenPGP. From rjh at sixdemonbag.org Wed Jul 11 02:27:54 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Jul 2012 20:27:54 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFCC5A4.8080708@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> Message-ID: <4FFCC88A.3080707@sixdemonbag.org> On 7/10/2012 8:15 PM, Robert J. Hansen wrote: > Then you need to stop using OpenPGP altogether, because you're already > generating SHA-1 signatures with your certificate which can be lifted > and dropped onto new messages if/when a preimage attack is introduced > against SHA-1. After re-reading this, I need to back off from this paragraph a bit. I apologize -- I've been up for almost 24 hours now and my thinking is a bit hazy. I know SHA-1 is hardwired into the spec, but without going to the spec and reading it closely I'm not 100% certain that SHA-1 *signatures* are hardwired into the spec, and frankly I'm too tired to do a detailed read of RFC4880 right now. My apologies. The general point remains, though, that if you believe SHA-1 is insecure then you need to stop using OpenPGP. A preimage collision against SHA-1 breaks OpenPGP into a lot of tiny little pieces. Little kids might still find those pieces useful for gluing to paper plates and giving to their parents to hang on refrigerators, but for the rest of us we're unlikely to have any further uses. :) From vedaal.nistar at gmail.com Wed Jul 11 06:41:09 2012 From: vedaal.nistar at gmail.com (vedaal) Date: Wed, 11 Jul 2012 00:41:09 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFCC88A.3080707@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> Message-ID: <4FFD03E5.9080002@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >The general point remains, though, that if you believe SHA-1 is insecure then you need to stop using OpenPGP. Well, Yes, and No. ;-) SHA1 is hardwired into the fingerprint of v4 keys. An open pgp consensus on a v5 key will not happen overnight. So when is it reasonable enough to suggest that SHA1 is broken enough to start working on a v5 key? vedaal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Acts of Kindness better the World, and protect the Soul Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP/QPlAAoJEFBvT6HTX7GGwUgQAI3eHOQ9eNxuuXM6yzdB9jm0 BoE8bGXu9TyVlRFqUEieVjzmHYisxlsipto5YLfxyYHNqpPIz7ZTbUrWA1pXDqNe pNZnxz6uRIW2qCof09D4jxdev7n4FzjZ0ugWY5wbb9alkJlqp59UTku+Oa+V47V6 yf4pl3CW2YSN1sB0roX4GY2K/UWa2I3cbllOIUFvBjXhWcm+b7qSmWkaY5O5yzrC zqh53KqSekcaQch+NVJibs71kTK1O5iOX9H4Oa69VCkhJXtaex6ZUSfwIrSv+vVl iJ6qH6LBYqF4hMg3QgkE/p2MEey4vOzBmOAp7CkL0IuZingFzIHu7mPIgc2wgxDz UvwK68hT7kZkRt501rELT4OwLJhIx9xth7DC/Rj1dhyGpZWZiGVgu1MRvziCIcrk di/yhTNQrcJGJCVf8oWH3tPkedaUNRBaksZNcNhbe5Gyes/rBBDPmmlmTR9AMcyG +Bl7nf3jfOM7UsVXOcyqEXDiuYpInmrbkkk2BRv8PxmvfI0Y3qW2Zk3RVNY7ZNb/ 8sSOVGD+BTmygUlYS07mwY1q3aWpBdBFTSEKa5pU/w3ZZtSPARj9+SfTLNLjeTLm UgTthE3SqHTMrJtWCsGmvGTR73PYcthQXqvJkCUTHA/mYtEOTkG7eKfiXyJytMz8 QeUvM1NtSkDT6ypGGmRn =+ApG -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Jul 11 07:56:47 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 01:56:47 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFD03E5.9080002@gmail.com> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> Message-ID: <4FFD159F.7060205@sixdemonbag.org> On 7/11/2012 12:41 AM, vedaal wrote: > SHA1 is hardwired into the fingerprint of v4 keys. As soon as a V5 key spec is released, I'll revise my statement. Until then, OpenPGP has an unfortunate dependency on hashes that do not have good long-term prospects. :) > So when is it reasonable enough to suggest that SHA1 is broken enough > to start working on a v5 key? V5 discussions will not kick off in earnest until NIST announces the new hash standard, or so I've heard people from the working group say. From r.ted.byers at gmail.com Tue Jul 10 20:27:10 2012 From: r.ted.byers at gmail.com (Ted Byers) Date: Tue, 10 Jul 2012 14:27:10 -0400 Subject: apache https gnupg Message-ID: <1a0a01cd5ec9$9ef05380$dcd0fa80$@gmail.com> I searched the above combination of keywords on http://marc.theaimsgroup.com/ and got nothing. I assume, then, that this group has no messages dealing with the question of whether or not I can use GnuPG to create certificates that I can use to support https on Apache. The more general searches I used provided lots on the details of creating certificates and keys for use in encrypting and signing documents, but nothing on the more specific questions of practical application. I actually have a couple concerns. One dealing with supporting HTTPS on the Apache web server (instead of buying one from, e.g., GoDaddy - and a related question being can I sign a web page, which may not be sent via https, so that the user viewing it knows it has not been altered in transit) and the other dealing with authentication of users submitting data to a web application that lives on Apache, and similarly the authentication of folk sending email to my server, in both cases, meaning, is the person providing the data who he says he is. For this second issue, it is a question of being able to support non-repudiation (i.e. to ensure a person can't enter data on one date and then deny he did so subsequently). I have read enough to know I can use GnuPG to encrypt data on my various machines, but I haven't yet found where to look for information dealing with practical application in securing web applications and proving the identity of users of those applications. In ecommerce, for example, one of the big risks involves customers buying a product or service and then demanding a refund claiming he didn't buy that product or service but rather someone was impersonating him. I am looking to see if there is a practical application of GnuPG to let me prove that a user is who he says he is and take that a step further in providing evidence that the user did, in fact, make the purchase he now denies (i.e. non-repudiation). I recall, when I first read about PGP, many years ago, there was a section that talked abstractly about non-repudiation, but now I am looking study the practicalities of applying it in a selection of web applications (and these applications do involve use of email, so that needs to be secured also). I don't expect anyone to write a tome on this, but a few links on, first, is it possible, and then, if so, how to deploy on Suse or Ubuntu Linux, would be appreciated. NB: I have a growing collection of tools I can use to support my efforts, so in a sense, this is a question of whether or not I can, and should, add GnuPG to my toolkit. Cheers Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml-gpg at m-privacy.de Wed Jul 11 12:15:58 2012 From: ml-gpg at m-privacy.de (Roman) Date: Wed, 11 Jul 2012 12:15:58 +0200 Subject: keytocard: bad secret key In-Reply-To: <9a721f5c13af57da4f887a7f9e6518c4@mail.secure-mail.biz> References: <9a721f5c13af57da4f887a7f9e6518c4@mail.secure-mail.biz> Message-ID: <4FFD525E.103@m-privacy.de> Am 10.07.2012 21:22, schrieb boson at z1p.biz: > I'm trying to save a 4096 bit RSA key to my OpenPGP smartcard v2.0 but I get an error about a "bad secret key". > > I use Ubuntu 10.04 with a self-compiled GnuPG 2.0.19 > > Verbose-mode doesn't tell more details and according to Google I am the only one with that problem... You should check if your smartcard reader can handle "extended APDU" as described here: http://pcsclite.alioth.debian.org/ccid.html I had only success with extended APDU readers with 4096bit keys. Roman From wk at gnupg.org Wed Jul 11 12:26:48 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jul 2012 12:26:48 +0200 Subject: very cautious :-) In-Reply-To: <5941084.tq991Cy71U@inno> (Hauke Laging's message of "Wed, 11 Jul 2012 01:22:42 +0200") References: <5941084.tq991Cy71U@inno> Message-ID: <87r4sioaon.fsf@vigenere.g10code.de> On Wed, 11 Jul 2012 01:22, mailinglisten at hauke-laging.de said: > gpg --options /dev/null --keyserver hkp://keys.gnupg.net --search-keys ... > gpg: external program calls are disabled due to unsafe options file > permissions Use --no-options instead. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 11 12:25:13 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jul 2012 12:25:13 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFD159F.7060205@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 11 Jul 2012 01:56:47 -0400") References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> Message-ID: <87vchuoara.fsf@vigenere.g10code.de> On Wed, 11 Jul 2012 07:56, rjh at sixdemonbag.org said: > V5 discussions will not kick off in earnest until NIST announces the new > hash standard, or so I've heard people from the working group say. And even then it will take 5 years or so until it it has been deployed widely. Even GnuPG 1.2 is still in use; despite that it has been declared EOL ages ago. The fingerprint and the special features building upon it (e.g. revocation keys) are targets for an attack based on a SHA-1 *pre-image* attack. We need to analyze the possible problems and if needed deploy workarounds for them. SHA-256 for signatures is already in widespread use - thus I don't see a problem right now. The real problem I see for GnuPG is that its maintenance is heavily under-financed and the pool of volunteers, taking care of it, is quite small. I am not sure whether PGP is in a better position; giving its current owner. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smickson at hotmail.com Wed Jul 11 14:38:08 2012 From: smickson at hotmail.com (Sam Smith) Date: Wed, 11 Jul 2012 08:38:08 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <20120710235945.GC158060@crustytoothpaste.ath.cx> References: , <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com>, <4FFB9D23.3020209@sixdemonbag.org>, , <4FFC37C4.60303@sixdemonbag.org>, <20120710235945.GC158060@crustytoothpaste.ath.cx> Message-ID: > I'd much rather fail to generate a signature than generate > one using an algorithm which is very weak. My feelings as well. Date: Tue, 10 Jul 2012 23:59:45 +0000 From: sandals at crustytoothpaste.net To: gnupg-users at gnupg.org Subject: Re: why is SHA1 used? How do I get SHA256 to be used? On Tue, Jul 10, 2012 at 10:10:12AM -0400, Robert J. Hansen wrote: > > SHA1 is no longer secure. > > At the present moment, SHA-1 is just fine. In the fairly near future, > anywhere between six months to a few years, I expect this will change. > But "SHA1 is no longer secure" is factually untrue, at least where > OpenPGP is concerned. SHA-1 is considered cryptographically broken. It does not provide the level of security it claims. Practically, collisions can be generated for 75 of the 80 rounds[0]. I hardly consider an algorithm this close to a collision "just fine". There's no need to run screaming to the exits, but a quick and orderly transition has been appropriate for some time. The time to move to something else is ending soon. > I don't recommend SHA-1 for new signatures, but if you have a choice > between sending a SHA-1 message which your recipient can verify > or a SHA-256 message which your recipient can't, well -- that math's > pretty easy to do. SHA-1 isn't a good choice for new signatures, but > it's a lot better than no signature. I don't generate signatures with algorithms I consider insecure because that leads to people being able to forge signatures in my name. If I use MD5, even for one message, that allows a moderately determined attacker to replay that signature on what is likely to become a fairly large set of messages. I'd rather avoid that, thank you. > > I'm not going to cater to people using really old versions, > > especially when security is involved. > > The good news is that no one's asking you to. You're only being > advised, "don't use --digest-algo SHA256, it's unwise and can break > interoperability. Use --personal-digest-preferences SHA256 instead." > This is the same advice that has been given by the GnuPG developers, by > the Enigmail team, and by many other people within the community. It's > a best-practices thing for GnuPG. The question is, will GnuPG fall back to SHA-1 if it's not in my digest preferences? I'd much rather fail to generate a signature than generate one using an algorithm which is very weak. [0] http://eprint.iacr.org/2011/641 -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 _______________________________________________ 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 healers at basicisp.net Wed Jul 11 15:50:03 2012 From: healers at basicisp.net (Healer 1) Date: Wed, 11 Jul 2012 08:50:03 -0500 Subject: Intro. Message-ID: <4FFD848B.6090604@basicisp.net> Good Day Folks, I am a retired doc 65 and a scrunch,a Master Bard & Priest to the Sanctuary of the Healers' Heart, and due to necessity I am becoming involved in signing and encryption I am somewhere in the mid range of computer skills better with Linux than Winblow$. I am a total noobe with both the signing & Encryption. I use T-bird with Enigmail and will have questions about it's use and some more on the workings of GNuPG . If I ask something that is common knowledge to you I ask your forbearance and ask for basic explanations initially. I'm sure that as I learn my questions will indicate that. I am also a musician, artisan, and writer as well. I am willing to help others as I learn. Be Well, Be at Peace and spend loving time with your families as we never know how long we'll be graced with their presence. In Service & In Health, Dr. C. From smickson at hotmail.com Wed Jul 11 16:09:10 2012 From: smickson at hotmail.com (Sam Smith) Date: Wed, 11 Jul 2012 10:09:10 -0400 Subject: How to "activate" gpg.conf entries? Message-ID: I've added the following 3 lines to my gpg.conf file: 1) to use stronger hash when supported by others, I added this line = personal-digest-preferences SHA256 2) to use the SHA256 hash when I Sign a message, I added this line = cert-digest-algo SHA256 3) to change what is used when a new key is generated I added this line = default-preference-list SHA256 SHA384 SHA512 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed If I am using the wrong command for my intended purpose, please do let me know :) What procedure should I now do to "activate" or put into effect these preferences? Once done, is there a way to verify that these preferences are in effect, how can I verify? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kf at sumptuouscapital.com Wed Jul 11 16:54:27 2012 From: kf at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 11 Jul 2012 16:54:27 +0200 Subject: How to "activate" gpg.conf entries? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-07-11 16:09, Sam Smith wrote: > I've added the following 3 lines to my gpg.conf file: > > 1) to use stronger hash when supported by others, I added this line > = *personal-digest-preferences SHA256* > > 2) to use the SHA256 hash when I Sign a message, I added this line > =*cert-digest-algo SHA256* This is not what cert-digest-algo does, I'd recommend removing this line at all, but; --cert-digest-algo name Use name as the message digest algorithm used when signing a key. Running the program with the command --version yields a list of supported algorithms. Be aware that if you choose an algorithm that GnuPG supports but other OpenPGP implementations do not, then some users will not be able to use the key signatures you make, or quite possibly your entire key. > > 3) to change what is used when a new key is generated I added this > line = *default-preference-list SHA256 SHA384 SHA512 SHA224 AES256 > AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed* Note that as per RFC4880 this will still not remove SHA1[0: 13.3.2.] or 3DES[0: 13.2.], as these are appended tacitly to be able to ensure a matching set between implementations. > > If I am using the wrong command for my intended purpose, please do > let me know :) > > What procedure should I now do to "activate" or put into effect > these preferences? Once done, is there a way to verify that these > preferences are in effect, how can I verify? > Clearsign some text and see what hash it yield? Also note what has been mentioned regarding the use of 1024 bit DSA keys, which are limited to the use of 160 bit hash algo. If you wish to use a non-truncated version of SHA256 and have such a key, you'll have to propagate to a new one. [0] http://tools.ietf.org/html/rfc4880 - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP/ZOjAAoJEBbgz41rC5UI5MMQAJih43IyXYh7BpxOe22PQkJS xc3F2sRfbyjyWE2trLyNhP+TVGFPeej7rx39wYzgr05VBktN0kavjQ5THWlS6P5T e6byMSdF0gfveEq8LVu87iDkR9105H9f2exoq+/DJA7DcLJ7DDtKtk6K7UBu2D02 x6Lu7kAx6ixqUVW+QwT/WCSEWhVe8ELOS923AergJl6f0UeUUFnpr+RHdH/gwz2d ejA77HlVgA85WcF6lkzvIXtmwWnMw/f7kDmOLyggtqIm2xu4C+woU6glyFpeJiym F0Zuj6IZRv22ZJhWbfiI691SXN+HaV5aZdPi2HwMdM2IF5E5XL82P4zwJgCAPgL/ Amywqdv0nWfJ3nBOY4YuzDmnhiIyvjjOCcJg2/GHBN0flKEJ+47wWTFqQkFGCUCg RWK8qPJJvihIaVXztyGwSDMqPSBAEBSA4FQ2JGphjDXcBBrBcgd1FpgInXY11ovq vf4NXSHtp7qkZTRS8xuu6IqomuKsjdHOAWwTbPMGkgw1XrR9UqAnHDuS7AFjVyiZ nU+gN0Ub6/OhEBID6ANFodEmL/TthpcrlyZK6IxEPrYiOwM64cnIZ0qmhNP0MBBu 2VpQJdMYTbHpIhPvLVdHuuBY/KRaceuhqkUtz8Ut6zGOK0/N260bAW8txfHkZQjH rVkNcAhTFX/nkqjMHpJy =t6mT -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Jul 11 17:03:12 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 11:03:12 -0400 Subject: On signatures, enforcement and authentication Message-ID: <4FFD95B0.2050201@sixdemonbag.org> First: This is not legal advice. I am not a lawyer. Consult a lawyer in your jurisdiction if you have specific questions. This is the rantings of a semi-informed layman. One of the big elephants in the room when talking about digital signatures is that we conflate several different things under the name "digital signature." The two major ones are *enforceable promises* and *message authentication*. These two things are quite distinct. ===== A digital signature by itself means absolutely nothing. What's important is that as a society we have decided we will enforce the solemnized promises made by our members: slightly less important, that we have a legal framework to enforce these solemnized promises: and utterly unimportant, the form in which these solemnized promises manifest. There have been successful lawsuits seeking to enforce financial instruments that have been scrawled in Magic Marker on a watermelon. Whether the solemnization is a sworn oath before a notary public, ink on a page, marker on a watermelon or bits on a hard drive is really quite insignificant. For a promise to be enforceable, it must be (a) made (b) unambiguously (c) by parties able to make enforceable promises (d) and with mutual benefit. If I promise you that I'll give you a ride to the supermarket, that's not an enforceable promise. If I promise you that I'll give you a ride to the supermarket and you promise to buy me a Diet Coke while you're there, that's suddenly become an enforceable promise: we are both mutually on the hook if we fail to live up to our obligations. We have social mechanisms in place to support these four requirements. Yesterday I signed a contract involving a large sum of money, but the other party refused to simply accept my signature. I had to go to a notary public and present two forms of identification before signing the document in the presence of the notary. The other party to the contract required this so that if we went to court I would have a very hard time saying, "Your Honor, I never signed that contract." We have other social, cultural and legal things, too -- a detailed list would go on for literally dozens, if not hundreds, of pages. The important thing is that there are *basically* four requirements for an enforceable promise, and we have a large number of tools to support this. So, what's the relevance of this to SHA-1 and MD5? Let me present to you an enforceable MD5 signature. You and I agree to a sale of stock. We want to do it completely electronically without any paper records. Neither of us trusts the other, and we're stuck using PGP 2.6 with its whole slew of problems: MD5, V3 keys and more. I send you a list of notary publics that I trust. You choose your own notary public from that list and visit the notary. I've already sent a copy of the document I wish for you to sign to that notary. The notary checks your ID, tells you to read the document, and if you wish to assent to it to electronically sign the document in his presence. You do so. The notary retains a copy of the contract, your digital signature, a photocopy of your ID and so forth. On my end, I do the same thing with a notary chosen from a list of ones that *you* trust. The notary I trust sends me your signed assent to the agreement, the notary you trust sends you my signed assent to the agreement. Now if either of us wants to break that agreement, how do we do this? The notaries will confirm that we read the agreement in their presences and signed the documents. Maybe you'll be able to argue that it wasn't you who signed, but an impostor armed with fake ID. Maybe you'll be able to claim the contract was ambiguously worded and should be interpreted in your favor. Maybe you can claim you were deranged and should not be held responsible for your choices. Maybe you can... etc. But none of those methods of repudiation have anything to do with cryptography or the weaknesses of MD5. And none of those methods of repudiation would be foreclosed or impossible if you were to use OpenPGP with SHA256-based signatures. ===== The preceding is, of course, completely irrelevant when you're trying to verify the signature on a software package. Here there's no desire to enforce a promise. All that you're trying to do is to ensure the provenance of a message, and that's where things like MD5 and SHA-1 weaknesses become very, very troubling. No argument there whatsoever. In the preceding example, the digital signature is phenomenally robust because there are trusted parties mediating the entire thing and human judgment is exercised throughout the process. In a verify-the-provenance situation, though, usually it's a completely automated process without either trusted mediators or human judgment. The important takeaway is this -- "Digital signature" is a phrase that covers an awful lot of ground. In some contexts digital signatures don't need any kind of collision resistance: just typing in "I agree to the terms of the above" would both be sufficient and enforceable. In other contexts you need as much collision resistance as possible. Ray Lee once said, "Every truth has a context." I'm not sure *every* truth has a context, but declaring certain hash functions as insecure for use in digital signatures is definitely context-sensitive. I think it would be good if we were to keep that in mind when talking about digital signatures -- it's possible for two people to be using the same words but have two completely different use cases in mind, and in the process have two completely different conversations. From mailinglisten at hauke-laging.de Wed Jul 11 17:09:06 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Jul 2012 17:09:06 +0200 Subject: scope of standard authority (was: Re: How to "activate" gpg.conf entries?) In-Reply-To: References: Message-ID: <1420324.vdnQq0x7ne@inno> Am Mi 11.07.2012, 16:54:27 schrieb Kristian Fiskerstrand: > Note that as per RFC4880 this will still not remove SHA1[0: 13.3.2.] > or 3DES[0: 13.2.], as these are appended tacitly to be able to ensure > a matching set between implementations. Does it make sense that a standard overrides a user's decision to prefer security over compatibility (sure, you can still check afterwards what has happened but that can be difficult especially if gpg is not used directly but called by a MUA e.g.)? As someone stated here recently, he would rather not make a signature at all than one which he considers unsafe. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Jul 11 17:11:44 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 11:11:44 -0400 Subject: How to "activate" gpg.conf entries? In-Reply-To: References: Message-ID: <4FFD97B0.7070402@sixdemonbag.org> On 7/11/2012 10:09 AM, Sam Smith wrote: > 1) to use stronger hash when supported by others, I added this line = > *personal-digest-preferences SHA256* I would suggest "SHA256 RIPEMD160", myself. There are no known attacks on RIPEMD160, and if you're in a situation that requires the use of a 160-bit hash it will allow you to fall back to a still-trusted hash rather than SHA-1. > 2) to use the SHA256 hash when I Sign a message, I added this line > =*cert-digest-algo SHA256* That's not what cert-digest-algo does. > 3) to change what is used when a new key is generated I added this line > = *default-preference-list SHA256 SHA384 SHA512 SHA224 AES256 AES192 AES > CAST5 ZLIB BZIP2 ZIP Uncompressed* There's nothing technically wrong with this, but I'd advise doing something different. Remember, the preflist on a certificate is (somewhat) misnamed: it's meant to show both capabilities *and* preferences. For instance, you can use Blowfish and Twofish and Camellia256 and whatnot. These are all believed to be safe, so there's really no reason to omit them from your certificate prefs. Push SHA-1 to the back of your hash prefs, certainly -- but if you don't have a strong reason to omit believed-safe algorithms from your pref list, I would consider it best to include them. > What procedure should I now do to "activate" or put into effect these > preferences? Once done, is there a way to verify that these preferences > are in effect, how can I verify? Sign a message and send it to the list. Don't forget to add "enable-dsa2" to your gpg.conf file *if* (a) you're using a DSA-1k signing key and (b) you want to be able to use truncated SHA256 with it. From rjh at sixdemonbag.org Wed Jul 11 17:13:46 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 11:13:46 -0400 Subject: scope of standard authority In-Reply-To: <1420324.vdnQq0x7ne@inno> References: <1420324.vdnQq0x7ne@inno> Message-ID: <4FFD982A.5050205@sixdemonbag.org> On 7/11/2012 11:09 AM, Hauke Laging wrote: > Does it make sense that a standard overrides a user's decision to prefer > security over compatibility (sure, you can still check afterwards what has > happened but that can be difficult especially if gpg is not used directly but > called by a MUA e.g.)? Yes. The entire point of a standard is to allow interoperation. That means there has to be some final fallback mode. SHA-1 is that fallback mode. With luck we'll see this get changed once the new hash standard is announced. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From smickson at hotmail.com Wed Jul 11 17:46:03 2012 From: smickson at hotmail.com (Sam Smith) Date: Wed, 11 Jul 2012 11:46:03 -0400 Subject: How to "activate" gpg.conf entries? In-Reply-To: References: , Message-ID: Thanks. The clearsign "test" worked. What does "cert-digest-algo" do? I read the description in the GnuPG manual and what you quoted, but I still don't understand. Could someone explain to me what cert-digest-algo does and how it differs from digest-algo when placed in gpg.conf? so "personal-digest-preferences SHA256" will specificy that SHA256 be used for digitally signing my messages, right? and "default-preference-list" is only used for when user generates a new key, right? > To: gnupg-users at gnupg.org > From: kf at sumptuouscapital.com > Subject: Re: How to "activate" gpg.conf entries? > Date: Wed, 11 Jul 2012 16:54:27 +0200 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2012-07-11 16:09, Sam Smith wrote: > > I've added the following 3 lines to my gpg.conf file: > > > > 1) to use stronger hash when supported by others, I added this line > > = *personal-digest-preferences SHA256* > > > > 2) to use the SHA256 hash when I Sign a message, I added this line > > =*cert-digest-algo SHA256* > > This is not what cert-digest-algo does, I'd recommend removing this > line at all, but; > --cert-digest-algo name > Use name as the message digest algorithm used when > signing a key. Running the program with the command > --version yields a list of supported algorithms. Be aware > that if you choose an algorithm that GnuPG supports > but other OpenPGP implementations do not, then some users > will not be able to use the key signatures you make, > or quite possibly your entire key. > > > > > 3) to change what is used when a new key is generated I added this > > line = *default-preference-list SHA256 SHA384 SHA512 SHA224 AES256 > > AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed* > > > Note that as per RFC4880 this will still not remove SHA1[0: 13.3.2.] > or 3DES[0: 13.2.], as these are appended tacitly to be able to ensure > a matching set between implementations. > > > > > > If I am using the wrong command for my intended purpose, please do > > let me know :) > > > > What procedure should I now do to "activate" or put into effect > > these preferences? Once done, is there a way to verify that these > > preferences are in effect, how can I verify? > > > > Clearsign some text and see what hash it yield? > > Also note what has been mentioned regarding the use of 1024 bit DSA > keys, which are limited to the use of 160 bit hash algo. If you wish > to use a non-truncated version of SHA256 and have such a key, you'll > have to propagate to a new one. > > [0] http://tools.ietf.org/html/rfc4880 > > > > - -- > - ---------------------------- > Kristian Fiskerstrand > http://www.sumptuouscapital.com > Twitter: @krifisk > - ---------------------------- > Corruptissima re publica plurim? leges > The greater the degeneration of the republic, the more of its laws > - ---------------------------- > This email was digitally signed using the OpenPGP > standard. If you want to read more about this > The book: Sending Emails - The Safe Way: An > introduction to OpenPGP security is now > available in both Amazon Kindle and Paperback > format at > http://www.amazon.com/dp/B006RSG1S4/ > - ---------------------------- > Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCAAGBQJP/ZOjAAoJEBbgz41rC5UI5MMQAJih43IyXYh7BpxOe22PQkJS > xc3F2sRfbyjyWE2trLyNhP+TVGFPeej7rx39wYzgr05VBktN0kavjQ5THWlS6P5T > e6byMSdF0gfveEq8LVu87iDkR9105H9f2exoq+/DJA7DcLJ7DDtKtk6K7UBu2D02 > x6Lu7kAx6ixqUVW+QwT/WCSEWhVe8ELOS923AergJl6f0UeUUFnpr+RHdH/gwz2d > ejA77HlVgA85WcF6lkzvIXtmwWnMw/f7kDmOLyggtqIm2xu4C+woU6glyFpeJiym > F0Zuj6IZRv22ZJhWbfiI691SXN+HaV5aZdPi2HwMdM2IF5E5XL82P4zwJgCAPgL/ > Amywqdv0nWfJ3nBOY4YuzDmnhiIyvjjOCcJg2/GHBN0flKEJ+47wWTFqQkFGCUCg > RWK8qPJJvihIaVXztyGwSDMqPSBAEBSA4FQ2JGphjDXcBBrBcgd1FpgInXY11ovq > vf4NXSHtp7qkZTRS8xuu6IqomuKsjdHOAWwTbPMGkgw1XrR9UqAnHDuS7AFjVyiZ > nU+gN0Ub6/OhEBID6ANFodEmL/TthpcrlyZK6IxEPrYiOwM64cnIZ0qmhNP0MBBu > 2VpQJdMYTbHpIhPvLVdHuuBY/KRaceuhqkUtz8Ut6zGOK0/N260bAW8txfHkZQjH > rVkNcAhTFX/nkqjMHpJy > =t6mT > -----END PGP SIGNATURE----- > > > _______________________________________________ > 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 Wed Jul 11 17:51:32 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jul 2012 17:51:32 +0200 Subject: How to "activate" gpg.conf entries? In-Reply-To: <4FFD97B0.7070402@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 11 Jul 2012 11:11:44 -0400") References: <4FFD97B0.7070402@sixdemonbag.org> Message-ID: <87a9z6nvnf.fsf@vigenere.g10code.de> On Wed, 11 Jul 2012 17:11, rjh at sixdemonbag.org said: > I would suggest "SHA256 RIPEMD160", myself. There are no known attacks > on RIPEMD160, and if you're in a situation that requires the use of a But only because RIPEMD160 does not get as much attention as SHA-1. I doubt that RIPEMD160 is in any way stronger than SHA-1. Even European authorities switched to SHA-1 a few years ago. Another advantage of SHA-1 and SHA-2 are the hardware accelerators available in modern CPUs. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From smickson at hotmail.com Wed Jul 11 17:57:29 2012 From: smickson at hotmail.com (Sam Smith) Date: Wed, 11 Jul 2012 11:57:29 -0400 Subject: How to "activate" gpg.conf entries? In-Reply-To: <4FFDA0C1.7070405@sumptuouscapital.com> References: , , <4FFDA0C1.7070405@sumptuouscapital.com> Message-ID: > For clearsigned messages, yes, for a message sent to someone else while using their public key, > it will depend on the capabilities specified in their preference. which command states this preference for when a message is sent to someone using their public key? the "default-preference-list" is for gen new key. Is it also used to tell others what preference I have for when they digitally sign a message that is intended for me? Or is there another command that specifies my preference for when they sign a message that is intended for me? Date: Wed, 11 Jul 2012 17:50:25 +0200 From: kristian.fiskerstrand at sumptuouscapital.com To: smickson at hotmail.com CC: gnupg-users at gnupg.org Subject: Re: How to "activate" gpg.conf entries? On 2012-07-11 17:46, Sam Smith wrote: > Thanks. The clearsign "test" worked. > > What does "cert-digest-algo" do? I read the description in the GnuPG > manual and what you quoted, but I still don't understand. Could > someone explain to me what cert-digest-algo does and how it differs > from digest-algo when placed in gpg.conf? Note that cert-digest-algo specify "when signing a key", which is different than signing a message. > so "personal-digest-preferences SHA256" will specificy that SHA256 be > used for digitally signing my messages, right? For clearsigned messages, yes, for a message sent to someone else while using their public key, it will depend on the capabilities specified in their preference. > and "default-preference-list" is only used for when user generates a > new key, right? > right -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Wed Jul 11 18:18:22 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Jul 2012 18:18:22 +0200 Subject: scope of standard authority In-Reply-To: <4FFD982A.5050205@sixdemonbag.org> References: <1420324.vdnQq0x7ne@inno> <4FFD982A.5050205@sixdemonbag.org> Message-ID: <2889269.RBWnCZPhji@inno> Am Mi 11.07.2012, 11:13:46 schrieb Robert J. Hansen: > The entire point of a standard is to allow interoperation. That means > there has to be some final fallback mode. IMHO the second sentence effectively rewrites the first to: "The entire point of a standard is to ENFORCE interoperation." I don't see the benefit of forcing someone to something in a security context if the direction is not to more but to less security. The two cases are: a) I try to send an email or sign a file. This fails with the hint that I have to correct my configuration. I then can decide whether to do that or not. b) I believe to make signatures of type X or Y only. But in rare cases such a "standard feature" (which maybe not more than a tiny share of the users know about) makes me unawarely create one of type Z. Who would choose (b) for himself and how big would the damage of getting there via (a) be for those? It seems to me that --digest-algo does have its use case and that the documentation is wrong: --digest-algo name [...] --personal-digest-preferences is the safe way to accomplish the same thing. It's obviously not the same. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From smickson at hotmail.com Wed Jul 11 19:06:06 2012 From: smickson at hotmail.com (Sam Smith) Date: Wed, 11 Jul 2012 13:06:06 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , , , , , <4FFDA0C1.7070405@sumptuouscapital.com>, Message-ID: To make sure I understand correctly: 1) cert-digest-algo SHA256 = will use SHA256 to sign KEYS with regardless of what preferences the key holder has stipulated 2) digest-algo SHA256 = will use SHA256 to sign MESSAGES with regardless of what preferences the recipient of the message has stipulated Do I understand these commands correctly? From: smickson at hotmail.com To: kristian.fiskerstrand at sumptuouscapital.com; gnupg-users at gnupg.org Subject: RE: How to "activate" gpg.conf entries? Date: Wed, 11 Jul 2012 11:57:29 -0400 > For clearsigned messages, yes, for a message sent to someone else while using their public key, > it will depend on the capabilities specified in their preference. which command states this preference for when a message is sent to someone using their public key? the "default-preference-list" is for gen new key. Is it also used to tell others what preference I have for when they digitally sign a message that is intended for me? Or is there another command that specifies my preference for when they sign a message that is intended for me? Date: Wed, 11 Jul 2012 17:50:25 +0200 From: kristian.fiskerstrand at sumptuouscapital.com To: smickson at hotmail.com CC: gnupg-users at gnupg.org Subject: Re: How to "activate" gpg.conf entries? On 2012-07-11 17:46, Sam Smith wrote: > Thanks. The clearsign "test" worked. > > What does "cert-digest-algo" do? I read the description in the GnuPG > manual and what you quoted, but I still don't understand. Could > someone explain to me what cert-digest-algo does and how it differs > from digest-algo when placed in gpg.conf? Note that cert-digest-algo specify "when signing a key", which is different than signing a message. > so "personal-digest-preferences SHA256" will specificy that SHA256 be > used for digitally signing my messages, right? For clearsigned messages, yes, for a message sent to someone else while using their public key, it will depend on the capabilities specified in their preference. > and "default-preference-list" is only used for when user generates a > new key, right? > right -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ _______________________________________________ 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 dshaw at jabberwocky.com Wed Jul 11 19:28:12 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 11 Jul 2012 13:28:12 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , , , , , <4FFDA0C1.7070405@sumptuouscapital.com>, Message-ID: <52675EEF-38D0-46E7-820F-B34A2730C603@jabberwocky.com> On Jul 11, 2012, at 1:06 PM, Sam Smith wrote: > To make sure I understand correctly: > > 1) cert-digest-algo SHA256 = will use SHA256 to sign KEYS with regardless of what preferences the key holder has stipulated > > 2) digest-algo SHA256 = will use SHA256 to sign MESSAGES with regardless of what preferences the recipient of the message has stipulated > > Do I understand these commands correctly? Not exactly. For signing keys (#1), there are no preferences, so there is nothing to override. It's just whatever you set cert-digest-algo to. Note, though, that this includes signing your own key, so if you make a subkey or add a user ID, the binding signature will also use that digest. For #2, you do understand correctly. David From dshaw at jabberwocky.com Wed Jul 11 19:57:58 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 11 Jul 2012 13:57:58 -0400 Subject: scope of standard authority (was: Re: How to "activate" gpg.conf entries?) In-Reply-To: <1420324.vdnQq0x7ne@inno> References: <1420324.vdnQq0x7ne@inno> Message-ID: On Jul 11, 2012, at 11:09 AM, Hauke Laging wrote: > Am Mi 11.07.2012, 16:54:27 schrieb Kristian Fiskerstrand: > >> Note that as per RFC4880 this will still not remove SHA1[0: 13.3.2.] >> or 3DES[0: 13.2.], as these are appended tacitly to be able to ensure >> a matching set between implementations. > > Does it make sense that a standard overrides a user's decision to prefer > security over compatibility (sure, you can still check afterwards what has > happened but that can be difficult especially if gpg is not used directly but > called by a MUA e.g.)? As someone stated here recently, he would rather not > make a signature at all than one which he considers unsafe. The standard specifies how algorithms are chosen and ensures that communication can always take place (eg. "if all else fails, pick 3DES"). It does not mandate that the message must be sent. It is obviously legal for a client to say "I settled on 3DES, but you don't permit 3DES, so I give up - I'm not able to continue". The standard controls how messages are generated, and if the client gives up before generating the message, the standard is not involved. It is not legal for the client to say "I settled on 3DES, but you don't permit 3DES, so I'm going to use AES instead". It's important to differentiate between signing and encryption here. For encryption, 3DES is the fallback algorithm, and the standard is very clear - it's an explicit MUST NOT to use any algorithm that isn't in the preference list. For signing, it's not as simple - for example, there is no explicit recipient (and therefore no preference list) when signing without encrypting, such as is done on a mailing list. The standard acknowledges this and leaves it up to the signer to pick an algorithm, with the obvious caveat that the signer can make a message that can't be verified. David From mailinglisten at hauke-laging.de Wed Jul 11 20:18:17 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Jul 2012 20:18:17 +0200 Subject: scope of standard authority (was: Re: How to "activate" gpg.conf entries?) In-Reply-To: References: <1420324.vdnQq0x7ne@inno> Message-ID: <1914921.JcqdthlI5z@inno> Am Mi 11.07.2012, 13:57:58 schrieb David Shaw: > For signing, it's not as simple - for example, there is > no explicit recipient (and therefore no preference list) when signing > without encrypting, such as is done on a mailing list. Is there any reason why known recipients should not be considered when signing only? I just noticed that gpg issues a warning if a recipient is given when signing only. But instead the public key could be used for hash selection. To avoid ambiguity this could fail if for any of the recipients the keys is missing. The calling application could check in advance which recipients have a key locally and only give those as recipients for the signing operation. As this is already done for encrypted signatures the required code should already be there. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 11 19:12:10 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 11 Jul 2012 19:12:10 +0200 Subject: How to "activate" gpg.conf entries? In-Reply-To: References: , , <4FFDA0C1.7070405@sumptuouscapital.com> Message-ID: <4FFDB3EA.1030800@sumptuouscapital.com> On 2012-07-11 17:57, Sam Smith wrote: > > For clearsigned messages, yes, for a message sent to someone else > while using their public key, > > it will depend on the capabilities specified in their preference. > > which command states this preference for when a message is sent to > someone using their public key? the "default-preference-list" is for > gen new key. Is it also used to tell others what preference I have for > when they digitally sign a message that is intended for me? Or is > there another command that specifies my preference for when they sign > a message that is intended for me? When public keys are involved it is necessary to determine common capabilities between the preferences of all. You can see these preferences e.g using gpg2 --edit-key 0xABCDEF01 and type "showpref". To set this preference for your own public key you'd use "setpref", which can also be used to update in accordance with the default-preference-list you set in gpg.conf. Note that for others to see the changes they will need an updated copy of the public key (typically; re-send it to the keyservers). -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Jul 11 17:50:25 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 11 Jul 2012 17:50:25 +0200 Subject: How to "activate" gpg.conf entries? In-Reply-To: References: , Message-ID: <4FFDA0C1.7070405@sumptuouscapital.com> On 2012-07-11 17:46, Sam Smith wrote: > Thanks. The clearsign "test" worked. > > What does "cert-digest-algo" do? I read the description in the GnuPG > manual and what you quoted, but I still don't understand. Could > someone explain to me what cert-digest-algo does and how it differs > from digest-algo when placed in gpg.conf? Note that cert-digest-algo specify "when signing a key", which is different than signing a message. > so "personal-digest-preferences SHA256" will specificy that SHA256 be > used for digitally signing my messages, right? For clearsigned messages, yes, for a message sent to someone else while using their public key, it will depend on the capabilities specified in their preference. > and "default-preference-list" is only used for when user generates a > new key, right? > right -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Jul 11 21:41:45 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 15:41:45 -0400 Subject: How to "activate" gpg.conf entries? In-Reply-To: <87a9z6nvnf.fsf@vigenere.g10code.de> References: <4FFD97B0.7070402@sixdemonbag.org> <87a9z6nvnf.fsf@vigenere.g10code.de> Message-ID: <4FFDD6F9.3000103@sixdemonbag.org> On 7/11/2012 11:51 AM, Werner Koch wrote: > But only because RIPEMD160 does not get as much attention as SHA-1. True, but I'm not certain I believe SHA256 is much better. Let's look over the history of Merkle-Damg?rd hashes: MD2 (broken 1997, preimages 2004) MD4 (broken 1991, preimages 2008, can generate collisions with pen and paper!) MD5 (broken 1996, preimages 2012 presumably, based on public reports about Flame) SHA-0 (broken 1998, no preimages) SHA-1 (broken 2005, no preimages) RIPEMD (broken ... uh ... when?) SHA256 (unbroken) RIPEMD-160 (unbroken) History has not been kind to the Merkle-Damg?rd construction. The fact OpenPGP only contains Merkle-Damg?rds has always bothered me: I'd feel much better if WHIRLPOOL had been standardized and included in the list. From rjh at sixdemonbag.org Wed Jul 11 22:27:15 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 16:27:15 -0400 Subject: Intro. In-Reply-To: <4FFD848B.6090604@basicisp.net> References: <4FFD848B.6090604@basicisp.net> Message-ID: <4FFDE1A3.4080305@sixdemonbag.org> On 7/11/2012 9:50 AM, Healer 1 wrote: > I am a retired doc 65 and a scrunch,a Master Bard & Priest to the > Sanctuary of the Healers' Heart, and due to necessity I am becoming > involved in signing and encryption... You may also be interested in joining the Enigmail users mailing list: http://www.mozdev.org/mailman/listinfo/enigmail/ As a general rule, you'll get faster responses to Enigmail questions on that list, and faster responses to GnuPG questions on this list. Welcome to the community. We hope you'll find information that's useful to you! :) From wk at gnupg.org Wed Jul 11 23:41:21 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jul 2012 23:41:21 +0200 Subject: How to "activate" gpg.conf entries? In-Reply-To: <4FFDD6F9.3000103@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 11 Jul 2012 15:41:45 -0400") References: <4FFD97B0.7070402@sixdemonbag.org> <87a9z6nvnf.fsf@vigenere.g10code.de> <4FFDD6F9.3000103@sixdemonbag.org> Message-ID: <87obnmm0vy.fsf@vigenere.g10code.de> On Wed, 11 Jul 2012 21:41, rjh at sixdemonbag.org said: > History has not been kind to the Merkle-Damg?rd construction. The fact > OpenPGP only contains Merkle-Damg?rds has always bothered me: I'd feel > much better if WHIRLPOOL had been standardized and included in the list. On Phil?s request we tried to limit proliferation of algorithms and tried to agree on a common and useful subset of the allowed algorithms. Back then WHIRLPOOL doesn?t gave a clear improvement on the size of a digest and thus we did not considered it as something useful. Hash algorithm research was kind of black magic and most of us assumed that the NSA folks tried their best to come up with a solid hash design. WHIRLPOOL was a bit of obscure back then. That all happened 12 to 15 years ago. The last discussion I recall was during the second AES conference in 2000(?). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Wed Jul 11 22:55:32 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 11 Jul 2012 21:55:32 +0100 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <87vchuoara.fsf@vigenere.g10code.de> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> <87vchuoara.fsf@vigenere.g10code.de> Message-ID: On Wed, Jul 11, 2012 at 11:25 AM, Werner Koch wrote: > On Wed, 11 Jul 2012 07:56, rjh at sixdemonbag.org said: > >> V5 discussions will not kick off in earnest until NIST announces the new >> hash standard, or so I've heard people from the working group say. > > And even then it will take 5 years or so until it it has been deployed > widely. Even GnuPG 1.2 is still in use; despite that it has been > declared EOL ages ago. > > The fingerprint and the special features building upon it > (e.g. revocation keys) are targets for an attack based on a SHA-1 > *pre-image* attack. We need to analyze the possible problems and if > needed deploy workarounds for them. SHA-256 for signatures is already > in widespread use - thus I don't see a problem right now. > > The real problem I see for GnuPG is that its maintenance is heavily > under-financed and the pool of volunteers, taking care of it, is quite > small. I am not sure whether PGP is in a better position; giving its > current owner. A bleak but realistic assessment. But one thing that might be helpful to explain is this: what needs to be in the V5 key format aside from the change in fingerprint hash? Aside from that issue, the V4 key format seems to have been resilient. What are the other issues that need to be addressed? Nicholas From sandals at crustytoothpaste.net Thu Jul 12 03:23:22 2012 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Thu, 12 Jul 2012 01:23:22 +0000 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFCC5A4.8080708@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> Message-ID: <20120712012322.GD158060@crustytoothpaste.ath.cx> On Tue, Jul 10, 2012 at 08:15:32PM -0400, Robert J. Hansen wrote: > There tends to be a lot of scaremongering in the world of crypto. I > think it's generally wise to be careful in our declarations. It is > enough to say SHA-1 is known to not meet its design specifications and > that some fairly devastating attacks against it will likely be coming > along in the near future. That's already a good enough reason to reduce > our usage of and dependency upon SHA-1. There's no need to fearmonger > about how the algorithm has already collapsed, because it hasn't. I'm not saying it has collapsed. I'm saying that it has weaknesses, and that the number and magnitude of the weaknesses continue to grow, and that I think it is imprudent to use SHA-1. I would much rather people make the move to something better now, because otherwise we'll all be stuck with SHA-1 long after it's insecure, just like it's been with MD5. > > Practically, collisions can be generated for 75 of the 80 rounds[0]. > > Right now, only random collisions can be generated. That's not any use > in forging a signature, which requires a preimage collision. A > cryptographic break is not the same as a practical exploit. It's an indication of weakness. I've seen lots of people that work with crypto claim that we don't need larger margins of security. The cost of computation is so small that I'd rather overdo it than regret my decision later. > > I don't generate signatures with algorithms I consider insecure > > because that leads to people being able to forge signatures in my > > name. > > Then you need to stop using OpenPGP altogether, because you're already > generating SHA-1 signatures with your certificate which can be lifted > and dropped onto new messages if/when a preimage attack is introduced > against SHA-1. Really? I'm pretty sure that I'm not generating SHA-1 signatures. This is signed using SHA-512, SHA-384, or SHA-256. When I sign another key, I use SHA-512. At least that's what I've configured GnuPG to do, and I'd be very surprised if it did not, in fact, do that. If it is using SHA-1, please report it to the list: it's a bug. > Let me make this really clear: if you believe SHA-1 is insecure, you > believe OpenPGP is insecure and you should stop using it. SHA-1 is > hardwired into the OpenPGP spec in a few different places and, as of > right now, cannot really be removed. The new V5 key format will almost > certainly change this, but V5 won't be coming out for a good long while yet. SHA-1, for my current key, is being used to generate my fingerprint. It's being used in MDCs when I encrypt a message. And it's being used instead of the default checksum for my private key. That's it. Since my private key remains solely in my possession and is not subject to tampering, what checksum is used is really irrelevant. Since I sign my messages when I encrypt them, the MDC is essentially redundant, since it would be apparent that they'd been tampered with. It is extremely unlikely that an attacker would be able to tamper with the encrypted message such that they could produce a valid, signed unencrypted message. And I'm personally not happy with the use of SHA-1 for the fingerprint, but it'll have to do for a while. I wish we had chosen RIPEMD-160 instead. I feel it's a better, more conservative design. > > If I use MD5, even for one message, that allows a moderately > > determined attacker to replay that signature on what is likely to > > become a fairly large set of messages. I'd rather avoid that, thank > > you. > > You've *already done this*. Really? Can you show an example? > If you truly believe this, stop using OpenPGP. Is my statement not true for MD5? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From vedaal.nistar at gmail.com Thu Jul 12 05:13:00 2012 From: vedaal.nistar at gmail.com (vedaal) Date: Wed, 11 Jul 2012 23:13:00 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <20120712012322.GD158060@crustytoothpaste.ath.cx> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <20120712012322.GD158060@crustytoothpaste.ath.cx> Message-ID: <4FFE40BC.8080108@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/11/2012 9:23 PM, brian m. carlson wrote: >>> If I use MD5, even for one message, that allows a moderately >>> determined attacker to replay that signature on what is likely to >>> become a fairly large set of messages. I'd rather avoid that, thank >>> you. >> >> You've *already done this*. > > Really? Can you show an example? If you *ever* signed a message with SHA1 and posted it publicly, (maybe in the 'olden days' before any vulnerability in SHA1 was known) then that signature could become a source for a forgery, whenever SHA1 becomes broken enough. (A clever, malicious attacker could backdate the clock, and have a forgery of something you did in the past, when you couldn't claim: "Hey, that's an obvious forgery! I'm on record as saying I would never use SHA1 to sign anything anymore!") vedaal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Acts of Kindness better the World, and protect the Soul Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP/kC7AAoJEFBvT6HTX7GGXV0P/jE4sQEIohwQ4s89wLRzLkji //WimhWcxBvuzSW/uTNaMwG1QwkDA/nbYwa3VUMv3BXNFA9bRaiLSG0QKo/4INo3 PPUqlC3zIS7H7up5BxU2kKw7F45IIjkYuny7A5cZr/0wldyThe6OJrGhO7AjnIv9 YfHc5ztaG115ch7fF5S2SqX2ygsoAGromsfo/0OyAtQssmFIzuEsTpDNQgFjieh7 rVPIIqedITwpcV+BHH5QSETVjC0ZzERMokC/RaJ+Ta14IwHfpSv5cAkFoqTMouiA oJxrGWROepnlD371gNZ/2dD1N76LBqGrxIMrc2ZbDI9UvM3GrAqv2aqNn0LOdfMz t/JhGj1DGUeRyCgR2R4+TNY9L5yh+rq0/1oMGmzDg7D1x3uhJFWChDSY2cPc+r+x xqjrsgEcQejcSOD0YaDSOTII/cMY6Xm8pB60GaVtw5uTAErO4aPlat977JhO97IF CWHp9VwdbKl8BepiKhq8N4yyIA/1pDVtYQt2Ua3QSUJ4uNUiUGyhrypkLdViC/ws 9jj7Hb1J4f7bjko+gGi36r0OGHd6zBE+a1auV6tli3fBvss1BJ8lSNqUVPO/leqB CNjNQNMF1GJnOqU4UvTT84KHnQBCHGWneS61a94YiOTyYQqs0BAYc2y/z6JaQY/u JmW/+vlA5PAoKr0aRSKe =8Ycl -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Jul 12 05:36:02 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 23:36:02 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <20120712012322.GD158060@crustytoothpaste.ath.cx> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <20120712012322.GD158060@crustytoothpaste.ath.cx> Message-ID: <4FFE4622.1030601@sixdemonbag.org> On 7/11/2012 9:23 PM, brian m. carlson wrote: > Really? I'm pretty sure that I'm not generating SHA-1 signatures. This is not necessarily relevant. Here's a thought experiment for you. Someone creates a DSA-1k key and uses --cert-digest-algo SHA256 and --enable-dsa2. This creates 160-bit truncated SHA256 hashes. This person is at risk from a SHA-1 preimage collision, *despite the fact they've never generated a single SHA-1 signature*. All the attacker has to do is create a message which SHA-1s out to the same value as the truncated SHA-256 of a legitimate message. At that point, the forgery becomes possible. I don't specifically know how you're using SHA-256. Nor do I especially want to know. What I do know is that there are a surprising number of ways a SHA-1 preimage attack can screw over even people who have never used SHA-256. Don't put too much faith in "if I switch to SHA-256 I don't need to worry about the SHA-1 attacks." It's probably not true. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jul 12 05:40:25 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 11 Jul 2012 23:40:25 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFE4622.1030601@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <20120712012322.GD158060@crustytoothpaste.ath.cx> <4FFE4622.1030601@sixdemonbag.org> Message-ID: <4FFE4729.3010008@sixdemonbag.org> On 7/11/2012 11:36 PM, Robert J. Hansen wrote: > want to know. What I do know is that there are a surprising number of > ways a SHA-1 preimage attack can screw over even people who have never > used SHA-256. s/SHA-256/SHA-1/ Apologies for the typo. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Thu Jul 12 06:09:44 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Jul 2012 06:09:44 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFE40BC.8080108@gmail.com> References: <20120712012322.GD158060@crustytoothpaste.ath.cx> <4FFE40BC.8080108@gmail.com> Message-ID: <4695736.Z9RO9r9P0I@inno> Am Mi 11.07.2012, 23:13:00 schrieb vedaal: > (A clever, malicious attacker could backdate the clock, > and have a forgery of something you did in the past, > when you couldn't claim: > > "Hey, that's an obvious forgery! > I'm on record as saying I would never use SHA1 to sign anything anymore!") So what? A signature over a broken hash alone is worthless no matter what its timestamp says. If you want to prove anything by a signature at a time when the hash is considered broken you have to prove that the signature existed before that time. And this proof can obviously not be based on the broken hash. Thus you have to sign all signatures you want to be able to use after the announcement that they are broken (which can, of course, come surprisingly) by another hash or rather you have to get them signed by a trusted third party if you want to use them against someone. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Thu Jul 12 06:10:11 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Jul 2012 22:10:11 -0600 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFCC5A4.8080708@sixdemonbag.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> Message-ID: <4FFE4E23.1010402@fifthhorseman.net> On 07/10/2012 06:15 PM, Robert J. Hansen wrote: > Right now, only random collisions can be generated. That's not any use > in forging a signature, which requires a preimage collision. If the attacker can convince you to sign a chosen text (perhaps one that looks reasonable), then a failure in the digest's collision-resistance could very well be used to replay that signature over a different (but colliding) text (which may not be something reasonable). This does not require a preimage collision. I'm not saying these attacks exist practically today against SHA1 (i don't know if they do), but collision-resistance is the relevant property, not resistance to pre-image attacks. > SHA-1 is > hardwired into the OpenPGP spec in a few different places and, as of > right now, cannot really be removed. The places where it is thoroughly "baked in" are the MDC (not relevant cryptographically) and the V4 fingerprint (where the relevant property is resistance to a preimage attack instead of resistance to generated collisions. >> If I use MD5, even for one message, that allows a moderately >> determined attacker to replay that signature on what is likely to >> become a fairly large set of messages. I'd rather avoid that, thank >> you. > > You've *already done this*. Where exactly has the original poster signed anything over an MD5 digest? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jul 12 06:33:17 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 00:33:17 -0400 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFE4E23.1010402@fifthhorseman.net> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFE4E23.1010402@fifthhorseman.net> Message-ID: <4FFE538D.7010605@sixdemonbag.org> You're arguing two different contradictory things here: > I'm not saying these attacks exist practically today against SHA1 (i > don't know if they do), but collision-resistance is the relevant > property, not resistance to pre-image attacks. And then: > The places where it is thoroughly "baked in" are the MDC (not relevant > cryptographically) and the V4 fingerprint (where the relevant property > is resistance to a preimage attack instead of resistance to generated > collisions. The relevant property can be resistance to preimage attack or it can be collision resistance. Pick a property and argue it, please. :) I am far more concerned about preimage attacks (which are the ultimate game-over) than random collisions (which affect a smaller fraction of the userbase). I'm not saying that random collisions are not troubling in their own right. > Where exactly has the original poster signed anything over an MD5 digest? Refer to my subsequent message, where I backed off from that statement and clarified I was referring to the poster was already relying on the safety of SHA-1 -- and was just in denial about it. If you believe SHA-1 is insecure and you want to avoid it at all costs, you need to avoid OpenPGP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Thu Jul 12 14:05:30 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Jul 2012 14:05:30 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <4FFE4E23.1010402@fifthhorseman.net> References: <4FFCC5A4.8080708@sixdemonbag.org> <4FFE4E23.1010402@fifthhorseman.net> Message-ID: <83884117.0gfTCfFk91@inno> Am Mi 11.07.2012, 22:10:11 schrieb Daniel Kahn Gillmor: > If the attacker can convince you to sign a chosen text (perhaps one that > looks reasonable), then a failure in the digest's collision-resistance > could very well be used to replay that signature over a different (but > colliding) text (which may not be something reasonable). This does not > require a preimage collision. But that is a problem only in that case that a collision algorithm is capable of creating (mostly ? some "random" data may be hidden in comments) useful data, isn't it? I am not familiar with the collision algorithms. Is all the effort useless if the reasonable document is slightly changed? I guess so. Does it make sense to require every document which one is to sign to be slightly changed (even if it's just a "typo" but this change would have to be determined by oneself not by the other party) before signing? > I'm not saying these attacks exist practically today against SHA1 (i > don't know if they do), but collision-resistance is the relevant > property, not resistance to pre-image attacks. But the problem of collision-resistance can be addressed organizationally, pre-image attacks cannot. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From smickson at hotmail.com Thu Jul 12 14:41:49 2012 From: smickson at hotmail.com (Sam Smith) Date: Thu, 12 Jul 2012 08:41:49 -0400 Subject: cert-digest-algo clarification In-Reply-To: <52675EEF-38D0-46E7-820F-B34A2730C603@jabberwocky.com> References: , , , , , <4FFDA0C1.7070405@sumptuouscapital.com>, , <52675EEF-38D0-46E7-820F-B34A2730C603@jabberwocky.com> Message-ID: regarding #1: you said there are no preferences. Assuming I don't set cert-digest-algo, what is the HASH that is used to sign keys with? > Subject: Re: cert-digest-algo clarification > From: dshaw at jabberwocky.com > Date: Wed, 11 Jul 2012 13:28:12 -0400 > CC: gnupg-users at gnupg.org > To: smickson at hotmail.com > > On Jul 11, 2012, at 1:06 PM, Sam Smith wrote: > > > To make sure I understand correctly: > > > > 1) cert-digest-algo SHA256 = will use SHA256 to sign KEYS with regardless of what preferences the key holder has stipulated > > > > 2) digest-algo SHA256 = will use SHA256 to sign MESSAGES with regardless of what preferences the recipient of the message has stipulated > > > > Do I understand these commands correctly? > > Not exactly. For signing keys (#1), there are no preferences, so there is nothing to override. It's just whatever you set cert-digest-algo to. Note, though, that this includes signing your own key, so if you make a subkey or add a user ID, the binding signature will also use that digest. For #2, you do understand correctly. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Thu Jul 12 14:45:41 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 12 Jul 2012 08:45:41 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , , , , , <4FFDA0C1.7070405@sumptuouscapital.com>, , <52675EEF-38D0-46E7-820F-B34A2730C603@jabberwocky.com> Message-ID: <75628C39-5E54-48B4-A30B-4F78943CC917@jabberwocky.com> On Jul 12, 2012, at 8:41 AM, Sam Smith wrote: > regarding #1: you said there are no preferences. Assuming I don't set cert-digest-algo, what is the HASH that is used to sign keys with? cert-digest-algo has no preferences (no ranked lists, etc). - it defaults to SHA-1, but you can override it as desired. Note that you can only override with an algorithm that works for the key you are making the certification with. For example, you can't use RIPEMD-160 with a DSA-2048 key. David From smickson at hotmail.com Thu Jul 12 16:28:01 2012 From: smickson at hotmail.com (Sam Smith) Date: Thu, 12 Jul 2012 10:28:01 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , Message-ID: What is the difference between "personal-digest-preferences" AND "default-preference-list" My understanding is that "default-preference-list" will define what is used for new key generation. Based on what I recently read in this mailing list, "default-preference-list" also defines the "showpref" command, which other users can see on my public key to know my preferences. Assuming this is all correct: what does "personal-digest-preferences" do? > To: smickson at hotmail.com > From: laurent.jumet at skynet.be > Subject: RE: cert-digest-algo clarification > Date: Thu, 12 Jul 2012 16:04:43 +0200 > > > Hello Sam ! > > Sam Smith wrote: > > > regarding #1: you said there are no preferences. Assuming I don't set > > cert-digest-algo, what is the HASH that is used to sign keys with? > > SHA-1 > > Here's an opinion: > http://www.debian-administration.org/users/dkg/weblog/48 > > -- > Laurent Jumet > KeyID: 0xCFAF704C -------------- next part -------------- An HTML attachment was scrubbed... URL: From smickson at hotmail.com Thu Jul 12 17:27:03 2012 From: smickson at hotmail.com (Sam Smith) Date: Thu, 12 Jul 2012 11:27:03 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , Message-ID: When I use "personal-digest-preferences", should I be inputting a list? Or is a single entry all that's necessary? > To: smickson at hotmail.com > From: laurent.jumet at skynet.be > Subject: RE: cert-digest-algo clarification > Date: Thu, 12 Jul 2012 17:08:46 +0200 > > > Hello Sam ! > > Sam Smith wrote: > > > What is the difference between "personal-digest-preferences" AND > > "default-preference-list" > > The latter is branded in your public key, using setpref in the key menu. After, you may send it to the servers in order to tell the whole World what preferences you'd like. > The first is set in your .CONF and tells your own GPG what to do. > > > My understanding is that "default-preference-list" will define what is > > used for new key generation. > > ...may be, I didn't try. > Better use showpref after generating, in order to launch setpref if still needed. > > -- > Laurent Jumet > KeyID: 0xCFAF704C -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Thu Jul 12 17:32:27 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Jul 2012 17:32:27 +0200 Subject: cert-digest-algo clarification In-Reply-To: References: Message-ID: <6850682.fFHKY6qqJi@inno> Am Do 12.07.2012, 11:27:03 schrieb Sam Smith: > When I use "personal-digest-preferences", should I be inputting a list? Or > is a single entry all that's necessary? Why don't you simply have a look at the documentation? --personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg2 --version to get a list of available algorithms, and use none to set no preference at all. This allows the user to safely override the algorithm chosen by the recipient key preferences, as GPG will only select an algorithm that is usable by all recipients. The most highly ranked digest algorithm in this list is also used when signing without encryption (e.g. --clearsign or --sign). -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From smickson at hotmail.com Thu Jul 12 17:39:44 2012 From: smickson at hotmail.com (Sam Smith) Date: Thu, 12 Jul 2012 11:39:44 -0400 Subject: cert-digest-algo clarification In-Reply-To: <6850682.fFHKY6qqJi@inno> References: , , , <6850682.fFHKY6qqJi@inno> Message-ID: It's overriding the recipient key preferences. So "default-preference-list" is embedded into the public key to tell others your preferences. But if I set a string for "personal-digest-preferences" then this string will override the "default-preference-list" that the other user set in his public key? This is not clear. Say I want to tell everyone, "Hey, I prefer you use SHA256 when communicating with me." What command should I use to communicate this? "default-preference-list" right? So "personal-digest-preferences" overrides this? From: mailinglisten at hauke-laging.de To: gnupg-users at gnupg.org Subject: Re: cert-digest-algo clarification Date: Thu, 12 Jul 2012 17:32:27 +0200 Am Do 12.07.2012, 11:27:03 schrieb Sam Smith: > When I use "personal-digest-preferences", should I be inputting a list? Or > is a single entry all that's necessary? Why don't you simply have a look at the documentation? --personal-digest-preferences string Set the list of personal digest preferences to string. Use gpg2 --version to get a list of available algorithms, and use none to set no preference at all. This allows the user to safely override the algorithm chosen by the recipient key preferences, as GPG will only select an algorithm that is usable by all recipients. The most highly ranked digest algorithm in this list is also used when signing without encryption (e.g. --clearsign or --sign). -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 _______________________________________________ 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 Thu Jul 12 17:52:17 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 11:52:17 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , , , <6850682.fFHKY6qqJi@inno> Message-ID: <4FFEF2B1.5060601@sixdemonbag.org> On 7/12/2012 11:39 AM, Sam Smith wrote: > Say I want to tell everyone, "Hey, I prefer you use SHA256 when > communicating with me." What command should I use to communicate > this? "default-preference-list" right? There's a difference between what you can enforce and what you might be able to suggest. The OpenPGP spec requires that no OpenPGP implementation will ever use any algorithm except those that are listed on your certificate as ones that your implementation understands. This list of "I can understand the following algorithms" can be found by 'gpg --edit-key [keyid] showpref'. Some OpenPGP implementations, such as GnuPG, will treat that set of capabilities as a list of preferences. If your prefs show up as "SHA256 SHA-1", for instance, an OpenPGP implementation would be forbidden from using RIPEMD160, but would be able to use SHA1. GnuPG would likewise be forbidden from using RIPEMD160, but would be more likely to use SHA-1 than SHA256. GnuPG might still use SHA-1, though! If the sender is using a DSA-1k key and does not have --enable-dsa2 active, SHA256 is disallowed for the signature, so GnuPG will have to fall back to SHA-1. The takeaway here is that the capabilities shown on your certificate ("gpg --edit-key [keyid] showpref") MAY be used as a preference list, are not guaranteed to be used as a preference list, and even if using an OpenPGP implementation that treats it as a preference list you may wind up getting stuck with SHA-1 anyway. > So "personal-digest-preferences" overrides this? No. personal-digest-preferences declares which digest algorithms you prefer to use and in which order. The certificate preferences declare which algorithms you are *capable* of using (and, for some implementations, which algorithms you prefer *other people* to use and in which order). From rjh at sixdemonbag.org Thu Jul 12 17:55:24 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 11:55:24 -0400 Subject: cert-digest-algo clarification In-Reply-To: <4FFEF2B1.5060601@sixdemonbag.org> References: , , , <6850682.fFHKY6qqJi@inno> <4FFEF2B1.5060601@sixdemonbag.org> Message-ID: <4FFEF36C.7060607@sixdemonbag.org> On 7/12/2012 11:52 AM, Robert J. Hansen wrote: > GnuPG would likewise be forbidden from using RIPEMD160, but would be > more likely to use SHA-1 than SHA256. Reverse those two, please. Clearly I need to go drink coffee directly from the pot -- I'm making far too many errors today. From mailinglisten at hauke-laging.de Thu Jul 12 17:58:20 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Jul 2012 17:58:20 +0200 Subject: cert-digest-algo clarification In-Reply-To: References: <6850682.fFHKY6qqJi@inno> Message-ID: <1994456.pRjJtltfUh@inno> Am Do 12.07.2012, 11:39:44 schrieb Sam Smith: > It's overriding the recipient key preferences. And sets the value for non-encrypted signatures. > So "default-preference-list" is embedded into the public key Into new keys. Existing keys need --edit-key 0x... setpref... > to tell others > your preferences. But if I set a string for "personal-digest-preferences" > then this string will override the "default-preference-list" that the other > user set in his public key? Yes. Overrides the order (but cannot make missing elements available). > Say I want to tell everyone, "Hey, I prefer you use SHA256 when > communicating with me." What command should I use to communicate this? > "default-preference-list" right? As you wrote: This information is (or rather can be) embedded in a key. Either by default-preference-list being defined at the creation time of the key or by --edit-key setpref. Have you read the documentation about --default-preference-list? --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. I don't find that unclear. > So "personal-digest-preferences" overrides this? The personal-digest-preferences setting in the configuration of *other* users may override the setting you may have made in your key. Your personal-digest- preferences setting is irrelevant for the signatures of others. You should read the documentation for the commands showpref and setpref, try them (in combination with --default-preference-list) and see what happens. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From smickson at hotmail.com Thu Jul 12 18:04:26 2012 From: smickson at hotmail.com (Sam Smith) Date: Thu, 12 Jul 2012 12:04:26 -0400 Subject: cert-digest-algo clarification In-Reply-To: <4FFEF2B1.5060601@sixdemonbag.org> References: , , , , , , <6850682.fFHKY6qqJi@inno> , <4FFEF2B1.5060601@sixdemonbag.org> Message-ID: Thx for this explanation. Is the "personal-digest-preferences" shown in the public key? Is this preference list something others can see (how do I make it appear in the public key)? If it is not displayed in the public key, I don't understand what good it is or how/where it would get used. > Date: Thu, 12 Jul 2012 11:52:17 -0400 > From: rjh at sixdemonbag.org > To: gnupg-users at gnupg.org > Subject: Re: cert-digest-algo clarification > > On 7/12/2012 11:39 AM, Sam Smith wrote: > > Say I want to tell everyone, "Hey, I prefer you use SHA256 when > > communicating with me." What command should I use to communicate > > this? "default-preference-list" right? > > There's a difference between what you can enforce and what you might be > able to suggest. > > The OpenPGP spec requires that no OpenPGP implementation will ever use > any algorithm except those that are listed on your certificate as ones > that your implementation understands. This list of "I can understand > the following algorithms" can be found by 'gpg --edit-key [keyid] showpref'. > > Some OpenPGP implementations, such as GnuPG, will treat that set of > capabilities as a list of preferences. If your prefs show up as "SHA256 > SHA-1", for instance, an OpenPGP implementation would be forbidden from > using RIPEMD160, but would be able to use SHA1. GnuPG would likewise be > forbidden from using RIPEMD160, but would be more likely to use SHA-1 > than SHA256. > > GnuPG might still use SHA-1, though! If the sender is using a DSA-1k > key and does not have --enable-dsa2 active, SHA256 is disallowed for the > signature, so GnuPG will have to fall back to SHA-1. > > The takeaway here is that the capabilities shown on your certificate > ("gpg --edit-key [keyid] showpref") MAY be used as a preference list, > are not guaranteed to be used as a preference list, and even if using an > OpenPGP implementation that treats it as a preference list you may wind > up getting stuck with SHA-1 anyway. > > > So "personal-digest-preferences" overrides this? > > No. personal-digest-preferences declares which digest algorithms you > prefer to use and in which order. The certificate preferences declare > which algorithms you are *capable* of using (and, for some > implementations, which algorithms you prefer *other people* to use and > in which order). > > _______________________________________________ > 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 smickson at hotmail.com Thu Jul 12 18:11:11 2012 From: smickson at hotmail.com (Sam Smith) Date: Thu, 12 Jul 2012 12:11:11 -0400 Subject: cert-digest-algo clarification In-Reply-To: <1994456.pRjJtltfUh@inno> References: , <6850682.fFHKY6qqJi@inno>, , <1994456.pRjJtltfUh@inno> Message-ID: The "setpref" and "showpref" commands appear to only relate to what is stipulated with the "default-preference-list". Setpref just resorts back to the "default" settings if "default-preference-list" is not given. So if one sets "default-preference-list" it's not necessary to set "personal-digest-preferences", right? I mean how are "personal-digest-preferences" even seen by others if SETPREF does not embed them in the key? From: mailinglisten at hauke-laging.de To: gnupg-users at gnupg.org Subject: Re: cert-digest-algo clarification Date: Thu, 12 Jul 2012 17:58:20 +0200 Am Do 12.07.2012, 11:39:44 schrieb Sam Smith: > It's overriding the recipient key preferences. And sets the value for non-encrypted signatures. > So "default-preference-list" is embedded into the public key Into new keys. Existing keys need --edit-key 0x... setpref... > to tell others > your preferences. But if I set a string for "personal-digest-preferences" > then this string will override the "default-preference-list" that the other > user set in his public key? Yes. Overrides the order (but cannot make missing elements available). > Say I want to tell everyone, "Hey, I prefer you use SHA256 when > communicating with me." What command should I use to communicate this? > "default-preference-list" right? As you wrote: This information is (or rather can be) embedded in a key. Either by default-preference-list being defined at the creation time of the key or by --edit-key setpref. Have you read the documentation about --default-preference-list? --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. I don't find that unclear. > So "personal-digest-preferences" overrides this? The personal-digest-preferences setting in the configuration of *other* users may override the setting you may have made in your key. Your personal-digest- preferences setting is irrelevant for the signatures of others. You should read the documentation for the commands showpref and setpref, try them (in combination with --default-preference-list) and see what happens. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 _______________________________________________ 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 Jul 12 16:16:58 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Jul 2012 16:16:58 +0200 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: (Nicholas Cole's message of "Wed, 11 Jul 2012 21:55:32 +0100") References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> <87vchuoara.fsf@vigenere.g10code.de> Message-ID: <87hatd12ud.fsf@gnupg.org> On Wed, 11 Jul 2012 22:55, nicholas.cole at gmail.com said: > But one thing that might be helpful to explain is this: what needs to > be in the V5 key format aside from the change in fingerprint hash? > Aside from that issue, the V4 key format seems to have been resilient. > What are the other issues that need to be addressed? We need to check the WG archives for a list. What I can remember are: - A new fingerprint scheme - A hard (non-changeable) expiration time - A different way to express timestamps (Y2038 annoyance and the hard Y2106 problem). An 8601 timestamp string should do. - Get rid of the old and optional protection schemes or even switch to a modern standard one. There are related things we need to change for signatures packets. It might also be a good time to replace PKCS#1.5, Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Thu Jul 12 18:34:49 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 12:34:49 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , , , , , , <6850682.fFHKY6qqJi@inno> , <4FFEF2B1.5060601@sixdemonbag.org> Message-ID: <4FFEFCA9.6090004@sixdemonbag.org> (Many people on this list have passionate feelings about HTML email. I understand these feelings and sympathize, but sometimes HTML is very useful for drawing particular attention to text.) > Thx for this explanation. You're quite welcome. > Is the "personal-digest-preferences" shown in the public key? Is this > preference list something others can see (how do I make it appear in > the public key)? If it is not displayed in the public key, I don't > understand what good it is or how/where it would get used. Things will become more clear if you actually do the gpg invocation I mentioned earlier. :) For instance, this is what happens when I type gpg --edit-key 0xD6B98E10 showpref. There's a lot of spam in the output, but the relevant stuff is relatively easy to find and is in boldface. (If you want to follow along yourself, just gpg --keyserver pool.sks-keyservers.net --recv-key 0xD6B98E10, and then run the gpg --edit-key command.) ------------------------------------------------------------------------ [rjh at isaiah ~]$ gpg --edit-key 0xD6B98E10 showpref Secret key is available. pub 2048D/D6B98E10 created: 2008-07-30 expires: never usage: SC trust: ultimate validity: ultimate sub 2048g/001892C2 created: 2008-07-30 expires: never usage: E [ultimate] (1). Robert J. Hansen [ultimate] (2) Robert J. Hansen [ultimate] (3) Robert J. Hansen [ultimate] (4) [jpeg image of size 14285] [ultimate] (5) Robert J. Hansen [ultimate] (6) Robert J. Hansen [ultimate] (1). Robert J. Hansen *Cipher: TWOFISH, BLOWFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, AES256, AES192, AES, 3DES, CAST5 Digest: SHA256, SHA224, SHA384, SHA512, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZIP, ZLIB, Uncompressed * Features: MDC, Keyserver no-modify [ultimate] (2) Robert J. Hansen *Cipher: TWOFISH, BLOWFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, AES256, AES192, AES, 3DES, CAST5 Digest: SHA256, SHA224, SHA384, SHA512, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZIP, ZLIB, Uncompressed* Features: MDC, Keyserver no-modify [ultimate] (3) Robert J. Hansen *Cipher: TWOFISH, BLOWFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, AES256, AES192, AES, 3DES, CAST5 Digest: SHA256, SHA224, SHA384, SHA512, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZIP, ZLIB, Uncompressed* Features: MDC, Keyserver no-modify [ultimate] (4) [jpeg image of size 14285] *Cipher: TWOFISH, BLOWFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, AES256, AES192, AES, 3DES, CAST5 Digest: SHA256, SHA224, SHA384, SHA512, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZIP, ZLIB, Uncompressed* Features: MDC, Keyserver no-modify [ultimate] (5) Robert J. Hansen *Cipher: TWOFISH, BLOWFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, AES256, AES192, AES, 3DES, CAST5 Digest: SHA256, SHA224, SHA384, SHA512, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZIP, ZLIB, Uncompressed* Features: MDC, Keyserver no-modify [ultimate] (6) Robert J. Hansen *Cipher: TWOFISH, BLOWFISH, CAMELLIA256, CAMELLIA192, CAMELLIA128, AES256, AES192, AES, 3DES, CAST5 Digest: SHA256, SHA224, SHA384, SHA512, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZIP, ZLIB, Uncompressed* Features: MDC, Keyserver no-modify ------------------------------------------------------------------------ If you import my certificate and play along at home, you'll see that embedded in my certificate is a list of what ciphers my implementation is capable of supporting. Since all the ciphers used in GnuPG are believed to be safe and secure, I see no reason to omit any of them. If you were to send me encrypted data, your GnuPG implementation would know that "I /may/ use any of my algorithms to encrypt traffic for Rob, but he /most prefers/ TWOFISH traffic and /least prefers/ CAST5 traffic." (For ciphers, 3DES is a mandatory entry: if you do not explicitly put it somewhere in the list, it appears at the end.) [1] It's similar, but slightly different, with the digests. I dislike SHA-1, but I dislike MD5 even more. I don't want to forbid people from sending me MD5-signed messages, because there's really no point to it: if I get a message that's signed using MD5, I'm just going to treat it as if it's not signed at all. Including MD5 doesn't hurt me. Since I really dislike MD5, I list it at the very end. Since I dislike SHA-1 almost as much, it's right there by MD5. (Just as there's a mandatory cipher, SHA-1 is a mandatory digest entry: if you do not explicitly put it somewhere in the list, it appears at the end.) Compression algorithms, likewise. BZIP2 gives better compression, ZIP and ZLIB are comparable compression-wise, uncompressed gives no compression, so I rank them in that order. ('Uncompressed' is the mandatory compression entry here.) So, if you go back to GnuPG and type gpg --edit-key [your key ID] showpref, you should be able to see what capabilities you're advertising to the world. And assuming your correspondents are using PGP or GnuPG, your correspondents will be treating this capability set as a preference list and will prefer to use higher-ranked algorithms. [1] Before you ask, "Why do you prefer Blowfish over Camellia256?" or anything like that, well --- I don't. Remember, this is fundamentally a /what ciphers will I permit someone to use?/ list, and secondarily a /what ciphers do I prefer?/ list. There is no real preference order here. All of these ciphers are so ludicrously strong that I think it's kind of crazy to have passionate feelings about one being better than another. It's sort of like getting into a passionate argument about whether King Kong, Godzilla, Mechagodzilla, Moth-Ra or the aliens from /Independence Day/ are the best at urban demolition. I mean, sure, technically I'm sure there's some answer there, but the reality is (a) people are handwaving what it means to be the "best at urban demolition," (b) any of the five could take the title depending on how one defines "best," and (c) I don't have time to waste on that nonsense. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Jul 12 18:38:21 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 12:38:21 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: , <6850682.fFHKY6qqJi@inno>, , <1994456.pRjJtltfUh@inno> Message-ID: <4FFEFD7D.80708@sixdemonbag.org> On 7/12/2012 12:11 PM, Sam Smith wrote: > I mean how are "personal-digest-preferences" even seen by others if > SETPREF does not embed them in the key? The preferences on the key are, as I mentioned, really a capability set, but other GnuPG implementations will treat it as the algorithms you prefer other people to use *when creating traffic meant for you*. personal-X-preferences applies to mail you send others. The preferences on your certificate apply to mail others send you. From mailinglisten at hauke-laging.de Thu Jul 12 18:39:19 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Jul 2012 18:39:19 +0200 Subject: cert-digest-algo clarification In-Reply-To: References: <1994456.pRjJtltfUh@inno> Message-ID: <23143044.QshkzhgH3q@inno> Am Do 12.07.2012, 12:11:11 schrieb Sam Smith: > The "setpref" and "showpref" commands appear to only relate to what is > stipulated with the "default-preference-list". "Appear"? Is that what the documentation says? Do you prefer telling us your guesses over reading the neccessary information? > Setpref just resorts back to the "default" settings if > "default-preference-list" is not given. This is true only if setpref is called without arguments. > So if one sets > "default-preference-list" it's not necessary to set > "personal-digest-preferences", right? Do you read what we tell you? How does this question fit to my statement (which you even quote)? The personal-digest-preferences setting in the configuration of other users may override the setting you may have made in your key. Your personal-digest- preferences setting is irrelevant for the signatures of others. Stop trying to understand it from reading, you obvously have problems with that. Take two keys, give them different preferences, make encrypted signatures with different settings of personal-digest-preferences and have a look at the results. > I mean how are > "personal-digest-preferences" even seen by others if SETPREF does not embed > them in the key? As you have been told several times by several people (let alone the clear documentation): personal-digest-preferences is not to be seen by others. --personal-digest-preferences is used with --sign --encrypt affecting a single signature affecting what your software does --default-preference-list is used with --gen-key --edit-key setpref affecting the preference lists in a key affecting what another person's software does Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Thu Jul 12 18:46:11 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 12:46:11 -0400 Subject: cert-digest-algo clarification In-Reply-To: <23143044.QshkzhgH3q@inno> References: <1994456.pRjJtltfUh@inno> <23143044.QshkzhgH3q@inno> Message-ID: <4FFEFF53.3050702@sixdemonbag.org> On 7/12/2012 12:39 PM, Hauke Laging wrote: > "Appear"? Is that what the documentation says? Do you prefer telling > us your guesses over reading the neccessary information? > Do you read what we tell you? How does this question fit to my > statement (which you even quote)? > Stop trying to understand it from reading, you obvously have problems > with that. Hauke, life's too short to be mean. If you're getting frustrated, then perhaps it would be best for you to take a step back and let someone who's not frustrated field the question. :) From dkg at fifthhorseman.net Thu Jul 12 18:59:47 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Jul 2012 10:59:47 -0600 Subject: why is SHA1 used? How do I get SHA256 to be used? In-Reply-To: <87hatd12ud.fsf@gnupg.org> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> <87vchuoara.fsf@vigenere.g10code.de> <87hatd12ud.fsf@gnupg.org> Message-ID: <4FFF0283.9080007@fifthhorseman.net> On 07/12/2012 08:16 AM, Werner Koch wrote: > On Wed, 11 Jul 2012 22:55, nicholas.cole at gmail.com said: > >> But one thing that might be helpful to explain is this: what needs to >> be in the V5 key format aside from the change in fingerprint hash? >> Aside from that issue, the V4 key format seems to have been resilient. >> What are the other issues that need to be addressed? > > We need to check the WG archives for a list. What I can remember are: > > - A new fingerprint scheme > > - A hard (non-changeable) expiration time > > - A different way to express timestamps (Y2038 annoyance and the hard > Y2106 problem). An 8601 timestamp string should do. > > - Get rid of the old and optional protection schemes or even switch to a > modern standard one. > > There are related things we need to change for signatures packets. It > might also be a good time to replace PKCS#1.5, some other points (from memory): * Issuer subpacket should use a full fingerprint, rather than a short keyID * designated revoker signature should embed full key instead of fingerprint. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From laurent.jumet at skynet.be Thu Jul 12 19:03:28 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Thu, 12 Jul 2012 19:03:28 +0200 Subject: cert-digest-algo clarification In-Reply-To: Message-ID: Hello Sam ! Sam Smith wrote: > When I use "personal-digest-preferences", should I be inputting a list? Or > is a single entry all that's necessary? Choose your preferences using this: ?????????????????????????????????????????????????????????? ? Cipher-Algos: ? Digest-Algos: ? Compress-Algos: ? ?????????????????????????????????????????????????????????? ? ? ? Z0 Uncompressed ? ? S1 IDEA ? H1 MD5 ? Z1 ZIP ? ? S2 3DES ? H2 SHA1 ? Z2 ZLIB ? ? S3 CAST5 ? H3 RIPEMD160 ? Z3 BZIP2 ? ? S4 BLOWFISH ? ? ? ? ? ? ? ? ? ? ? ? S7 AES ? ? ? ? S8 AES192 ? H8 SHA256 ? ? ? S9 AES256 ? H9 SHA384 ? ? ? S10 TWOFISH ? H10 SHA512 ? ? ? S11 CAMELLIA128 ? H11 SHA224 ? ? ? S12 CAMELLIA192 ? ? ? ? S13 CAMELLIA256 ? ? ? ?????????????????????????????????????????????????????????? Then, write it in numbers (easier than the whole word, but not everybody likes this :-) in GPG.CONF; looks like this: default-preference-list S10 S9 S4 S8 S12 S11 S13 S3 S2 S1 S7 H8 H3 H11 H10 H9 H2 H1 Z3 Z2 Z1 Z0 personal-cipher-preferences S10 S9 S4 S8 S12 S11 S13 S3 S2 S1 S7 personal-digest-preferences H8 H3 H11 H10 H9 H2 H1 personal-compress-preferences Z3 Z2 Z1 Z0 After that, run setpref to brand your key with the same digits than default-preference-list : setpref S10 S9 S4 S8 S12 S11 S13 S3 S2 S1 S7 H8 H3 H11 H10 H9 H2 H1 Z3 Z2 Z1 Z0 Verify with pref if your key is branded, and send it to the servers. -- Laurent Jumet KeyID: 0xCFAF704C From rjh at sixdemonbag.org Thu Jul 12 19:59:43 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 12 Jul 2012 13:59:43 -0400 Subject: cert-digest-algo clarification In-Reply-To: References: Message-ID: <4FFF108F.10608@sixdemonbag.org> On 7/12/2012 1:03 PM, Laurent Jumet wrote: > Choose your preferences using this: This is not recommended. The codes are meant for machine use. They're easy to parse and machines never get confused between "H1" and "H2". The names are meant for human use. They're easy to read, easy to understand, easy to remember. From smickson at hotmail.com Fri Jul 13 14:33:03 2012 From: smickson at hotmail.com (Sam Smith) Date: Fri, 13 Jul 2012 08:33:03 -0400 Subject: cert-digest-algo clarification In-Reply-To: <23143044.QshkzhgH3q@inno> References: , <1994456.pRjJtltfUh@inno>, , <23143044.QshkzhgH3q@inno> Message-ID: Thanks everyone for all you help explaining. I really appreciate it. Although Hauke did get a bit mean. And Hauke: I did read ALL the documentation (printed it off)--prior to sending out the first question. I read several different pieces of documentation over the preceding days prior to emailing here. I also read Q&A stuff online. And I'm not stupid. A big thanks to Nick for helping me finally to understand exactly what lists are being compared. Here's what I understand, hopefully I got it right this time: default-preferences-list 1) the setpref command will embed this list into the public key so that the list is viewable by others 2) the highest preference listed in each category is used to generate new keys with personal-digest-preferences AND personal-cipher-preferences AND personal-compress-preferences 1) these lists are used to find a "best fit" by comparing what's in them to the other person's default-preferences-list. Seeks to match highest preference of both parties. (this is what was confusing to me--at first, I thought the default-preferences-list of both parties would be compared.) 2) the highest preference listed is used for --symmetric encryption From: mailinglisten at hauke-laging.de To: gnupg-users at gnupg.org Subject: Re: cert-digest-algo clarification Date: Thu, 12 Jul 2012 18:39:19 +0200 Am Do 12.07.2012, 12:11:11 schrieb Sam Smith: > The "setpref" and "showpref" commands appear to only relate to what is > stipulated with the "default-preference-list". "Appear"? Is that what the documentation says? Do you prefer telling us your guesses over reading the neccessary information? > Setpref just resorts back to the "default" settings if > "default-preference-list" is not given. This is true only if setpref is called without arguments. > So if one sets > "default-preference-list" it's not necessary to set > "personal-digest-preferences", right? Do you read what we tell you? How does this question fit to my statement (which you even quote)? The personal-digest-preferences setting in the configuration of other users may override the setting you may have made in your key. Your personal-digest- preferences setting is irrelevant for the signatures of others. Stop trying to understand it from reading, you obvously have problems with that. Take two keys, give them different preferences, make encrypted signatures with different settings of personal-digest-preferences and have a look at the results. > I mean how are > "personal-digest-preferences" even seen by others if SETPREF does not embed > them in the key? As you have been told several times by several people (let alone the clear documentation): personal-digest-preferences is not to be seen by others. --personal-digest-preferences is used with --sign --encrypt affecting a single signature affecting what your software does --default-preference-list is used with --gen-key --edit-key setpref affecting the preference lists in a key affecting what another person's software does Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 _______________________________________________ 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 klaus.layer at gmx.de Sun Jul 15 15:37:16 2012 From: klaus.layer at gmx.de (Klaus Layer) Date: Sun, 15 Jul 2012 15:37:16 +0200 Subject: key search does not work with gpg2 Message-ID: <1598866.DEg4GZLvgC@e9a4bfs47> Hi, I am doing a search for key B973BA7B with gpg: gpg --version gpg (GnuPG) 1.4.11 gpg --keyserver hkp://109.230.243.87 --search-key B973BA7B gpg: searching for "B973BA7B" from hkp server 109.230.243.87 (1) NetBank AG 1024 bit DSA key B973BA7B, created: 2000-09-27 The key is found. Same search with gpg2: gpg2 --version gpg (GnuPG) 2.0.17 libgcrypt 1.5.0 gpg2 --keyserver hkp://109.230.243.87 --search-key B973BA7B gpg: searching for "B973BA7B" from hkp server 109.230.243.87 gpg: key "B973BA7B" not found on keyserver the key will not be found. Known error, or am I doing something wrong? Thanks, Klaus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 665 bytes Desc: This is a digitally signed message part. URL: From kristian.fiskerstrand at sumptuouscapital.com Sun Jul 15 15:45:55 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 15 Jul 2012 15:45:55 +0200 Subject: key search does not work with gpg2 In-Reply-To: <1598866.DEg4GZLvgC@e9a4bfs47> References: <1598866.DEg4GZLvgC@e9a4bfs47> Message-ID: <5002C993.4000507@sumptuouscapital.com> On 2012-07-15 15:37, Klaus Layer wrote: > Hi, > > I am doing a search for key B973BA7B with gpg: > ... > > Known error, or am I doing something wrong? > Hi Klaus, Since you know the key ID I'd recommend trying two things; (i) replace --search-key with --recv-key ; gpg2 --keyserver 109.230.243.87 --recv-key B973BA7B (ii) Prefix the key id with 0x as gpg2 --keyserver 109.230.243.87 --search-key 0xB973BA7B -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From klaus.layer at gmx.de Sun Jul 15 16:37:02 2012 From: klaus.layer at gmx.de (Klaus Layer) Date: Sun, 15 Jul 2012 16:37:02 +0200 Subject: key search does not work with gpg2 In-Reply-To: <3573303.gZ11Ac6j97@inno> References: <1598866.DEg4GZLvgC@e9a4bfs47> <3573303.gZ11Ac6j97@inno> Message-ID: <2836302.xHOx44yVGQ@e9a4bfs47> Am Sonntag, 15. Juli 2012, 15:47:36 schrieb Hauke Laging: > Am So 15.07.2012, 15:37:16 schrieb Klaus Layer: > > gpg2 --keyserver hkp://109.230.243.87 --search-key B973BA7B > > gpg2 --keyserver hkp://109.230.243.87 --search-key 0xB973BA7B > > works. > > > Known error, or am I doing something wrong? > > I can't tell you whether that's a bug or a feature. > > > Hauke Thanks, Kristian & Hauke your are right. 0x makes the difference. From mailinglisten at hauke-laging.de Sun Jul 15 15:47:36 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 15 Jul 2012 15:47:36 +0200 Subject: key search does not work with gpg2 In-Reply-To: <1598866.DEg4GZLvgC@e9a4bfs47> References: <1598866.DEg4GZLvgC@e9a4bfs47> Message-ID: <3573303.gZ11Ac6j97@inno> Am So 15.07.2012, 15:37:16 schrieb Klaus Layer: > gpg2 --keyserver hkp://109.230.243.87 --search-key B973BA7B gpg2 --keyserver hkp://109.230.243.87 --search-key 0xB973BA7B works. > Known error, or am I doing something wrong? I can't tell you whether that's a bug or a feature. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Sun Jul 15 19:40:58 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 15 Jul 2012 19:40:58 +0200 Subject: proposal: signature usage for offline mainkeys (secure policy documents) Message-ID: <7946238.S92KriLYtz@inno> Hello, until yesterday I considered the capabilities (signing, decrypting) of an offline mainkey irrelevant as it is usually never used for these operations and thus recommended to create offline mainkeys without explicit capabilities. This attitude has just changed. I would like to tell you why. I hope this is a new thought and useful to some readers (don't hesitate to let me know :-) ). As some of you may remember I consider it important for a security infrastructure to know the meaning that a user gives its crypto tool(s). I can see that someone has e.g. a 2048 bit RSA key but I usually don't know whether this is an offline key (used in a highly secure environment only), a key on a smartcard or even a key which has been uploaded to a server for e.g. using crypto webmail. AFAIK today there is no standardized way of describing the security and usage of keys and signatures. The best you can do is write a signature policy, sign it (with limited validity) and put its URL in your signatures (--set-policy- url). But how can you be sure that the policy document is valid? Think of such a document for an insecure key. The document says something like "This key is rather insecure". The key gets compromised (without the owner noticing), the attacker writes a new document ("This is a very secure smartcard key."), signs it and replaces the old one by it. My previous consideration was that the only solution for this problem was to have the others sign not only your key but your policy document, too. This has, of course, the serious drawback that is becomes quite hard to change this document. Then it came to my mind that offline storage of the mainkey usually creates two different levels of crypto actions which the mainky is capable of. By allowing a mainkey to sign (and encrypt) you get interesting new opportunities. If the policy document is signed by the offline mainkey (by using 0x12345678! instead of 0x12345678) then its signature is very trustworthy. So you could create two documents: One describing the signature policy (which may change and easily be signed again by the mainkey) and one describing the key security which should never be changed (as this usually does not make much sense) and gets signed by those who certify the key (at best by their mainkey ;-) ). On the other hand this offers the possibility of a higher security level for encryption thus reducing the need for a second key. But IMHO this introduces a serious risk of confusion so I do not generally recommend that. Besides this possibility which is available by todays's tools I would love to see some standard there (for making this information machine readable): A simple XML definition and a corresponding set of signature notations which allow statements of useful precision about the usage and security of a key. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From healers at basicisp.net Mon Jul 16 14:53:49 2012 From: healers at basicisp.net (Healer 1) Date: Mon, 16 Jul 2012 07:53:49 -0500 Subject: Gnupg-users Digest, Vol 106, Issue 5 In-Reply-To: References: Message-ID: <50040EDD.6090003@basicisp.net> Good day Hauke, I am new to the list and have finally found the time to take a good look at the digests. As I look at Digest, Vol 106, Issue 5 I note the varied issues with SHA 1. I would like the advantage of the SHA 256, however I was not able to find the conf file. All I found was the gnupconf.exe file with no practical way to view it. For now I will assume I've erred and just ask, where do I find the appropriate file? Sorry if it's a dumb question but I'm new both to this list and cryptography, so your assistance would be of help. If it's too noob a question just say so and I'll not bother you folks again. Thanks in advance. Dr. C. On 7/10/2012 19 13, gnupg-users-request at gnupg.org wrote: > Send Gnupg-users mailing list submissions to > gnupg-users at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-users > or, via email, send a message with subject or body 'help' to > gnupg-users-request at gnupg.org > > You can reach the person managing the list at > gnupg-users-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-users digest..." > > > Today's Topics: > > 1. Re: why is SHA1 used? How do I get SHA256 to be used? > (Hauke Laging) ""SNIP"" From rjh at sixdemonbag.org Mon Jul 16 15:11:23 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Jul 2012 09:11:23 -0400 Subject: Gnupg-users Digest, Vol 106, Issue 5 In-Reply-To: <50040EDD.6090003@basicisp.net> References: <50040EDD.6090003@basicisp.net> Message-ID: <500412FB.7080904@sixdemonbag.org> On 07/16/2012 08:53 AM, Healer 1 wrote: > I would like the advantage of the SHA 256, however I was not able to > find the conf file. All I found was the gnupconf.exe file with no > practical way to view it. For now I will assume I've erred and just > ask, where do I find the appropriate file? On Windows Vista and above, look in: C:\Users\[your user name]\AppData\Roaming\GnuPG On Windows XP, look in: C:\Documents and Settings\[your user name]\Application Data\GnuPG > Sorry if it's a dumb question It's not a dumb question at all, and we're happy to help. :) From smickson at hotmail.com Mon Jul 16 15:17:01 2012 From: smickson at hotmail.com (Sam Smith) Date: Mon, 16 Jul 2012 09:17:01 -0400 Subject: Gnupg-users Digest, Vol 106, Issue 5 In-Reply-To: <50040EDD.6090003@basicisp.net> References: , <50040EDD.6090003@basicisp.net> Message-ID: On Ubuntu, config file found at: ~/.gnupg/gpg.conf On WinXP, config file found at: C:\Documents and Settings\\Application Data\gnupg\gpg.conf On Win7, config found at: C:\Users\\AppData\Roaming\gnupg\ If you do not find the file at the specified location, you can just create it. For example, say you navigate to ~/.gnupg/ folder in Ubuntu but there is no gpg.conf file. Just open gedit (or notepad on Windows) and save the empty document as "gpg.conf" (on windows make sure to change the setting to show file extensions). Then add your configurations to this file as needed,. > Date: Mon, 16 Jul 2012 07:53:49 -0500 > From: healers at basicisp.net > To: gnupg-users at gnupg.org > Subject: Re: Gnupg-users Digest, Vol 106, Issue 5 > > Good day Hauke, > I am new to the list and have finally found the time to take a good > look at the digests. As I look at Digest, Vol 106, Issue 5 I note the > varied issues with SHA 1. I would like the advantage of the SHA 256, > however I was not able to find the conf file. All I found was the > gnupconf.exe file with no practical way to view it. For now I will > assume I've erred and just ask, where do I find the appropriate file? > Sorry if it's a dumb question but I'm new both to this list and > cryptography, so your assistance would be of help. If it's too noob a > question just say so and I'll not bother you folks again. Thanks in advance. > Dr. C. > > On 7/10/2012 19 13, gnupg-users-request at gnupg.org wrote: > > Send Gnupg-users mailing list submissions to > > gnupg-users at gnupg.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > or, via email, send a message with subject or body 'help' to > > gnupg-users-request at gnupg.org > > > > You can reach the person managing the list at > > gnupg-users-owner at gnupg.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Gnupg-users digest..." > > > > > > Today's Topics: > > > > 1. Re: why is SHA1 used? How do I get SHA256 to be used? > > (Hauke Laging) > ""SNIP"" > > > _______________________________________________ > 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 Mon Jul 16 18:44:06 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Jul 2012 18:44:06 +0200 Subject: Gnupg-users Digest, Vol 106, Issue 5 In-Reply-To: <50040EDD.6090003@basicisp.net> (Healer 1's message of "Mon, 16 Jul 2012 07:53:49 -0500") References: <50040EDD.6090003@basicisp.net> Message-ID: <87wr23odux.fsf@vigenere.g10code.de> On Mon, 16 Jul 2012 14:53, healers at basicisp.net said: > varied issues with SHA 1. I would like the advantage of the SHA 256, > however I was not able to find the conf file. All I found was the gpgconf --list-dirs shows all configured directories. You want to look at the line starting with homedir. The value after the colon is the directory you are looking for. If you notice a '%' in that value, it is an escape sequence similar to what is used with URL. Examples: "C%3A/foo/bar" translates to "C:/foo/bar" "C%3A\my%25dir" translates to "C:\my%dir" You may need to enter the '\' instead of the '/' in some Windows tools. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From emylistsddg at gmail.com Mon Jul 16 23:39:34 2012 From: emylistsddg at gmail.com (eMyListsDDg) Date: Mon, 16 Jul 2012 14:39:34 -0700 Subject: getting gnupg keys from old computer to new In-Reply-To: <4FFF0283.9080007@fifthhorseman.net> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> <87vchuoara.fsf@vigenere.g10code.de> <87hatd12ud.fsf@gnupg.org> <4FFF0283.9080007@fifthhorseman.net> Message-ID: <1012348556.20120716143934@gmail.com> i used the wingnupg to install gnupg on a notebook i'm retiring. i mainly used the app and keys for my email client, "thebat". i've installed gnupg on the new notebook, how do i get the keys from the old computer into gnupg on the new computer? tia From rjh at sixdemonbag.org Tue Jul 17 00:51:59 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Jul 2012 18:51:59 -0400 Subject: getting gnupg keys from old computer to new In-Reply-To: <1012348556.20120716143934@gmail.com> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> <87vchuoara.fsf@vigenere.g10code.de> <87hatd12ud.fsf@gnupg.org> <4FFF0283.9080007@fifthhorseman.net> <1012348556.20120716143934@gmail.com> Message-ID: <50049B0F.8000801@sixdemonbag.org> Find the GnuPG configuration directory (on Windows XP it's usually C:\Documents and Settings\[username]\Application Data\GnuPG, on Windows Vista and beyond C:\Users\[username]\AppData\Roaming\GnuPG) and copy that to the appropriate directory on your new laptop. Once you've copied it, go into the directory and delete the random_seed file. random_seed should never be copied between machines. From mika.henrik.mainio at hotmail.com Tue Jul 17 11:15:29 2012 From: mika.henrik.mainio at hotmail.com (Mika Suomalainen) Date: Tue, 17 Jul 2012 12:15:29 +0300 Subject: getting gnupg keys from old computer to new In-Reply-To: <1012348556.20120716143934@gmail.com> References: <4FFB655C.4030200@sixdemonbag.org> <4FFB8DA5.4070203@gmail.com> <4FFB9D23.3020209@sixdemonbag.org> <4FFC37C4.60303@sixdemonbag.org> <20120710235945.GC158060@crustytoothpaste.ath.cx> <4FFCC5A4.8080708@sixdemonbag.org> <4FFCC88A.3080707@sixdemonbag.org> <4FFD03E5.9080002@gmail.com> <4FFD159F.7060205@sixdemonbag.org> <87vchuoara.fsf@vigenere.g10code.de> <87hatd12ud.fsf@gnupg.org> <4FFF0283.9080007@fifthhorseman.net> <1012348556.20120716143934@gmail.com> Message-ID: <50052D31.3090101@hotmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17.07.2012 00:39, eMyListsDDg wrote: > i've installed gnupg on the new notebook, how do i get the keys > from the old computer into gnupg on the new computer? Open terminal and run ``` gpg --export-secret-keys -a > secring.asc gpg --export -a > pubring.asc ``` Then files secring.asc and pubring.asc should appear at your home folder. On new computer, just run ``` gpg --import secring.asc gpg --import pubring.asc ``` when they are in your home folder and they should get imported. - -- Mika Suomalainen NOTICE! I am on mobile broadband with very limited time, so I cannot read emails very much. The best time to contact me is probably weekends when I have better connectivity with good luck. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Homepage: http://mkaysi.github.com/ Comment: gpg --keyserver pool.sks-keyservers.net --recv-keys 82A46728 Comment: Public key: http://mkaysi.github.com/PGP/key.txt Comment: Fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728 Comment: Why do I (clear)sign emails? http://git.io/6FLzWg Comment: Please send plaintext instead of HTML. http://git.io/TAc0cg Comment: Please don't toppost. http://git.io/7-VB3g Comment: Please remove PGP lines in replies. http://git.io/nvHrDg Comment: Charset of this message should be UTF-8. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJQBS0uAAoJEE21PP6CpGconkkP/ReU6sUe0POGCMcgkZbh1LYH x4UvQGQXhDB21MhZRw+0IjfUd2jXuitaz983jMxmxedteB6z2SYo+mFHl+IGWEOd dya98Pa3frwicZ3Gdtj8uCW15fex/CnYtOUwz6YcleLkvUo1GKlJMrfxAaQk65RM JyklNO3VWEB7A75q+UBqpkOuGjmkdfMPji5gPWB1o/MvwDQE0KfjzZIyFamHanAS IeoNYL8x8btlQF8gX6ISeebs8ZFjO/6cY76RXGpznHroWEsi7EejXkBQg2gpKYyJ kZoVSB3Vs4j4B1cTJRBk/uSnCB4ziKvBYCof6PJAGDj+5Q3IvvgOnmr5FYaDDZOP zmJTSBLQYHaJYmZU/olGBf7mGy+hRXxj4+VfyXCLsFPdkBOkOXn7y0nBz+3pHncg GRD/Zr9bB3I51iZgOqzP781MkEhOMm5EXH1AZQSE1fgJKL/NjQjEcHrAIP1v44CQ kf1eYkeIWrzRJG8nfvB/DL23NZrnJNjQX26MP38WsgYYYpK6tdzyUFimH9g6/IME 72WZKXO6kZ/sYzVvnHz5TmuVsNqrjYBHrMBLulcayg2uiaAFx/r7xvUEYEjsixJC vj/BTD9FvGhG8YDz2StUBhnLyutNHBslDcTiuwVQ92wjYqB8ChOKXjnl9B843m40 PbAgbOgpS+GR6xrf/h3v =Z3iu -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Tue Jul 17 11:37:35 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 17 Jul 2012 11:37:35 +0200 Subject: getting gnupg keys from old computer to new In-Reply-To: <50052D31.3090101@hotmail.com> References: <1012348556.20120716143934@gmail.com> <50052D31.3090101@hotmail.com> Message-ID: <2467843.e7DHQ6O1yL@inno> Am Di 17.07.2012, 12:15:29 schrieb Mika Suomalainen: > Open terminal and run > > ``` > gpg --export-secret-keys -a > secring.asc > gpg --export -a > pubring.asc Was my first idea, too, but Rob's suggestion is much better as this covers neither the trustdb nor the configuration files or log files. There's not much useless stuff in that directory. Doesn't make sense to copy single files. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From knorris671 at gmail.com Wed Jul 18 06:16:24 2012 From: knorris671 at gmail.com (Kevin Norris) Date: Tue, 17 Jul 2012 21:16:24 -0700 Subject: Unable to edit card Message-ID: Hi all, I got a CryptoStick back in November, set it up then and don't remember password/pin I set. I reset it using back to factory defaults, now whenever I try to change the pin (using default password) it doesn't allow me: Your selection? 1 Error changing the PIN: Input/output error 1 - change PIN 2 - unblock PIN 3 - change Admin PIN 4 - set the Reset Code Q - quit ----- Same thing happens when I try to change the name: gpg/card> admin Admin commands are allowed gpg/card> name Cardholder's surname: Norris Cardholder's given name: Kevin gpg: error setting Name: Card error Anyone know why this is happening? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jw72253 at verizon.net Thu Jul 19 05:17:35 2012 From: jw72253 at verizon.net (John) Date: Wed, 18 Jul 2012 22:17:35 -0500 Subject: GPA and Windows Message-ID: On this website http://www.gnupg.org/download/supported_systems.en.html, I see this statement: 64 bit versions of Windows are NOT supported. The source may build but there is no guarantee that the resulting binaries do what you expect them to do. We plan to work on it, iff [sic] there are enough requests for it. I have it installed on a 64-bit Win7 OS, and so far as I have seen, it appears to be working fine. Even so, I do want to voice my request officially, if I knew where the polling station was located. Thanks. From jw72253 at verizon.net Thu Jul 19 06:39:44 2012 From: jw72253 at verizon.net (John) Date: Wed, 18 Jul 2012 23:39:44 -0500 Subject: GPA and Directory Manager Message-ID: I have GPA 0.9.1 with GnuPG 2.0.17 installed on 64-bit Win7. When I look at the Backend Preferences, everything on the Directory Manager tab is greyed out. Is that normal for a non-server machine, or is there a setting I would have to make in one of the configuration files to make these features functional? Thanks. From antispam06 at sent.at Fri Jul 20 17:51:38 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Fri, 20 Jul 2012 17:51:38 +0200 Subject: KeePass or any other password wallet to store and transport keys Message-ID: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> I don't know much about security and cryptography. So what do you think about this combination? Is it any safer or is just a waste of time with the conversion to ASCII and back? Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From expires2012 at rocketmail.com Sat Jul 21 18:29:13 2012 From: expires2012 at rocketmail.com (MFPA) Date: Sat, 21 Jul 2012 17:29:13 +0100 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> Message-ID: <5910450551.20120721172913@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 20 July 2012 at 4:51:38 PM, in , antispam06 at sent.at wrote: > I don't know much about security and cryptography. So > what do you think about this combination? Is it any > safer or is just a waste of time with the conversion to > ASCII and back? What combination? Give people a clue! - -- Best regards MFPA mailto:expires2012 at rocketmail.com Don't learn safety rules by accident... -----BEGIN PGP SIGNATURE----- iQCVAwUBUArY3qipC46tDG5pAQpFQAQAmcYnurxg5k/tQ6aXYJzrqJFcKUa+C4Iz prCANZgiywgA9yguFxAmkeD5A2UJTPmRebVb3dv2uKJyYHgxq1mjW2cdTIle5A2K yRgI+4ZffuqfV9BFNE6JNwUsR6nv8Go5P8U9KhnykssDJrNEIK3bxviESEHxNRd0 KbqQHN/R8as= =44jv -----END PGP SIGNATURE----- From expires2012 at rocketmail.com Sat Jul 21 18:34:21 2012 From: expires2012 at rocketmail.com (MFPA) Date: Sat, 21 Jul 2012 17:34:21 +0100 Subject: GPA and Windows In-Reply-To: References: Message-ID: <479955528.20120721173421@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 19 July 2012 at 4:17:35 AM, in , John wrote: > We plan to work on it, iff [sic] there are enough requests for it. "Iff" is a widely used and recognised shorthand which means "if and only if." - -- Best regards MFPA mailto:expires2012 at rocketmail.com No matter what a man's past may have been, his future is spotless. -----BEGIN PGP SIGNATURE----- iQCVAwUBUAraEqipC46tDG5pAQps7gP/Y9FjkGA0a7gv1zF2Fv1WSlA3bhidoQbJ TdMklfNdlz+P4+EzitC1erFp7QEwKoQZXviQELHZLAp/x5BBlaO0Acorm8ZBLHb+ LZREodqpuVZDeuHmYk8nbEtV0X38nu9W4cPtRPuujuym4o7g36FjmxFCOU0rhmkF 7QPtebz4UUc= =PU7R -----END PGP SIGNATURE----- From antispam06 at sent.at Sat Jul 21 20:57:30 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Sat, 21 Jul 2012 20:57:30 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <5910450551.20120721172913@my_localhost> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <5910450551.20120721172913@my_localhost> Message-ID: <1342897050.10047.140661104955997.0A170B1E@webmail.messagingengine.com> On Sat, Jul 21, 2012, at 17:29, MFPA wrote: > > I don't know much about security and cryptography. So > > what do you think about this combination? Is it any > > safer or is just a waste of time with the conversion to > > ASCII and back? > > What combination? Give people a clue! My fault. Keepass or other password wallet to store and transport keys instead of the regular keyring. From dougb at dougbarton.us Sat Jul 21 23:12:30 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 21 Jul 2012 14:12:30 -0700 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> Message-ID: <500B1B3E.3020607@dougbarton.us> On 07/20/2012 08:51, antispam06 at sent.at wrote: > I don't know much about security and cryptography. So what do you think > about this combination? Is it any safer or is just a waste of time with > the conversion to ASCII and back? We can't answer this question intelligently because you haven't described your threat model. In other words, what danger would the wallet guard against? -- If you're never wrong, you're not trying hard enough From antispam06 at sent.at Sun Jul 22 01:26:03 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Sun, 22 Jul 2012 01:26:03 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500B1B3E.3020607@dougbarton.us> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> Message-ID: <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> On Sat, Jul 21, 2012, at 14:12, Doug Barton wrote: > On 07/20/2012 08:51, antispam06 at sent.at wrote: > > I don't know much about security and cryptography. So what do you think > > about this combination? Is it any safer or is just a waste of time with > > the conversion to ASCII and back? > > We can't answer this question intelligently because you haven't > described your threat model. In other words, what danger would the > wallet guard against? Hmm? that's an excellent question. I never formulated it this way. I guess computer theft. The other possible scenarios are far less probable. From dougb at dougbarton.us Sun Jul 22 03:46:57 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 21 Jul 2012 18:46:57 -0700 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> Message-ID: <500B5B91.70607@dougbarton.us> On 07/21/2012 16:26, antispam06 at sent.at wrote: > On Sat, Jul 21, 2012, at 14:12, Doug Barton wrote: >> On 07/20/2012 08:51, antispam06 at sent.at wrote: >>> I don't know much about security and cryptography. So what do you think >>> about this combination? Is it any safer or is just a waste of time with >>> the conversion to ASCII and back? >> >> We can't answer this question intelligently because you haven't >> described your threat model. In other words, what danger would the >> wallet guard against? > > Hmm? that's an excellent question. I never formulated it this way. I > guess computer theft. The other possible scenarios are far less > probable. Still doesn't answer the question. :) What bad thing are you worried about happening if someone gets your keyring? -- If you're never wrong, you're not trying hard enough From faramir.cl at gmail.com Sun Jul 22 18:12:59 2012 From: faramir.cl at gmail.com (Faramir) Date: Sun, 22 Jul 2012 12:12:59 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> Message-ID: <500C268B.8050001@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 20-07-2012 11:51, antispam06 at sent.at escribi?: > I don't know much about security and cryptography. So what do you > think about this combination? Is it any safer or is just a waste of > time with the conversion to ASCII and back? If your secret key is password protected, placing it inside a keepass file would add a second (maybe unneeded) layer of protection, and you can chose a different encryption algorithm than GnuPG uses, so if one algo gets broken, the other would hold. But it seems unlikely encryption algos get broken anytime soon, so weak link probably is the password chosen. Of course, I'm not an expert, so I may be totally wrong. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQDCaLAAoJEMV4f6PvczxAQcIH/335Q3wGH9w94u5Klq3Tm5qq DZivYjuwf52A8s6LmtyiOP4RbYbfz89vzHcgeqCjBI7RX0QNQGrlSBwhLKm1VWVH 7MryVBpKBKARDwDxwUD2t4sLf6tgZU+QidHKg5tuWuGTF0jEHVaciZi9kKcS3ed2 i2H1CdwY2yCH4dOcb1MQ9a1gk7QBbnI8VCHTY7EwMHtvRSZVFEgUjySOTFKf+Omz zuuXDvikfmY/Tbd7fRfSCzPMw5cwtSq8TLXVucA0XeQQhSqFmtxzAsvEKe5CD53l pNZX+JLveVM6VfhNK+yVtOFRCegNJRoAUyMHVwCG4RUZBzXcIrZ9A+/Hi6Vf4DI= =zHN+ -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Jul 22 22:52:44 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 22 Jul 2012 16:52:44 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500C268B.8050001@gmail.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> Message-ID: <500C681C.2020201@sixdemonbag.org> On 7/22/2012 12:12 PM, Faramir wrote: > If your secret key is password protected, placing it inside a keepass > file would add a second (maybe unneeded) layer of protection, and you > can chose a different encryption algorithm than GnuPG uses, so if one > algo gets broken, the other would hold. Not necessarily. This idea of 'stacking algorithms improves strength' is tempting, but it can just as easily reduce strength or do nothing. Imagine you have a simple substitution cipher, where each letter gets moved up three positions in the alphabet (ROT3). Then, in order to make this 'stronger', you re-encrypt it using ROT5. You're not producing 'two levels' of encryption which have to be broken individually, you're producing a single ROT8 encryption and fooling yourself about the level of security you actually have. Cryptography is a subtle art, and algorithms interact with each other in deeply surprising and counterintuitive ways. Before advocating that algorithms be composed together to achieve certain results, it's good to make sure that these compositions are cryptanalytically sound. :) From jeroen at budts.be Sun Jul 22 21:52:37 2012 From: jeroen at budts.be (Jeroen Budts) Date: Sun, 22 Jul 2012 21:52:37 +0200 Subject: GPG key to authenticate to SSH? Message-ID: <500C5A05.5050209@budts.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all! A few days ago I started wondering whether it is possible to use my GPG key to authenticate myself to SSH (instead of using a regular SSH-key). (To be more correct: an Authentication subkey on my GPG key) I started Googling and found some information which learned me that it seems to be possible but that it is not really straight forward. During this search I learned about (amongst others) gpg-agent with the - --enable-ssh-support option and the gpgkey2ssh script. It seemed to me that I would be able to use my GPG keys to authenticate to SSH using gpg-agent. However, it did not work. (I also used the gpgkey2ssh script on my subkey so I could add it to the authorized_keys on the server) After some more trying and googling, I discovered monkeysphere [1]. While using this I could get it to work, by doing `monkeysphere subkey-to-ssh-agent`. However this seems to export the subkey as a passwordless version to hand it over to `ssh-add`. So this would have to be done everytime after restarting my X-session. Also it seems a bit duplicate when I'm using gpg-agent, which already knows about my gpg-keys, that it should export my key and then re-add it to gpg-agent with ssh-add. Is it somehow possible to 'automatically' use my GPG subkey for SSH session when I'm using GPG-Agent? Or am I missing something here? Please note that I'm using XFCE (Xubuntu) which uses Gnome-Keyring by default so that might possibly also interfere with some of this. [1] http://web.monkeysphere.info/getting-started-user/ Thx for any help! Jeroen - -- website: http://budts.be/ - twitter: @teranex ___________________________________ Registered Linux User #482240 - GetFirefox.com - ubuntu.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCAAGBQJQDFoFAAoJEBrqc/v4ufiMn4gP/3dyu3L/2Oa7gAANqAr0WlQg cnotzD/CFhhQ14cc9qVYVQ/FaSO5nCU5GuyHhMV/vFHCyOAxOF4NpSDDXcioJnbJ jEBI2HM2kliHQrKtx9GkWXr/YCDadmqmIWUD47R8u4fAbeQMVvbynB2TIkBf756Z CbSZT7rBxDt+whBOzo5t6VW9FO+cAx62GQzGRILoxnx7gQeqztyNxOb1CK905FKU n5wdxxgXL0MfvihBuU/8Fmt6MzVUS/3eWCCK74IjxALlVTdS/ezlHrk7/P/ZJ7oL tP8+E+Xp5hVoD/iNxY3k1PbEZgqfJk7EDoTBZ9Bm9Y861vuJPZrzjJfTiCCyzkEh SmQ/rMjFfSt49DN1B4W8/lwnDcBqVUv/s5NzF9vRUgol9goxif1GCcIdDzK3I2GY gOzvhhmfSlT0qWI25Q4TaarBttB4xgHKhMIGl6Fq5jSzH2MUsNnIs1muNb/won9f gQajQUq2+IPL9WV1yFmLF6d90kFRZpXm3s3s4ZVcQSfcAS4VY8zvOAk3d2tfIlEF nPtUZ/dIr5qGsCravz8W7oKdjP15fmzXHlgpFEUM30nJzXfX5Z2E0eGOBmkQUFGn gKeFGndTnuKlhuIQaygJoIFNZGek6MdxH7NqHxjemT4e38PtdvPzGO3vD5+iQv5d lmqMJAlPJ0Xs7OGOzdoP =A8Fs -----END PGP SIGNATURE----- From antispam06 at sent.at Sun Jul 22 23:51:19 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Sun, 22 Jul 2012 23:51:19 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500B5B91.70607@dougbarton.us> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> Message-ID: <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> On Sat, Jul 21, 2012, at 18:46, Doug Barton wrote: > On 07/21/2012 16:26, antispam06 at sent.at wrote: > > Hmm? that's an excellent question. I never formulated it this way. I > > guess computer theft. The other possible scenarios are far less > > probable. > > Still doesn't answer the question. :) What bad thing are you worried > about happening if someone gets your keyring? Having a few private files opened with the key that resides on the same hard drive unit, which I know it's a no?no. From antispam06 at sent.at Mon Jul 23 01:22:59 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Mon, 23 Jul 2012 01:22:59 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500C681C.2020201@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> Message-ID: <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> On Sun, Jul 22, 2012, at 16:52, Robert J. Hansen wrote: > On 7/22/2012 12:12 PM, Faramir wrote: > > If your secret key is password protected, placing it inside a keepass > > file would add a second (maybe unneeded) layer of protection, and you > > can chose a different encryption algorithm than GnuPG uses, so if one > > algo gets broken, the other would hold. > > Not necessarily. This idea of 'stacking algorithms improves strength' > is tempting, but it can just as easily reduce strength or do nothing. > > Imagine you have a simple substitution cipher, where each letter gets > moved up three positions in the alphabet (ROT3). Then, in order to make > this 'stronger', you re-encrypt it using ROT5. You're not producing > 'two levels' of encryption which have to be broken individually, you're > producing a single ROT8 encryption and fooling yourself about the level > of security you actually have. Interesting. But I meant in my original unclear post something along the change of encryption. Moving keys off the keychain into armored text strings pushed as comments into empty or bogus entries into a password vault. > Cryptography is a subtle art, and algorithms interact with each other in > deeply surprising and counterintuitive ways. Before advocating that > algorithms be composed together to achieve certain results, it's good to > make sure that these compositions are cryptanalytically sound. :) Very interesting. So having a keepass database or a gpg keychain on a Truecrypt drive might make them both more vulnerable? From dougb at dougbarton.us Mon Jul 23 01:25:38 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 22 Jul 2012 16:25:38 -0700 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> Message-ID: <500C8BF2.70409@dougbarton.us> On 07/22/2012 14:51, antispam06 at sent.at wrote: > On Sat, Jul 21, 2012, at 18:46, Doug Barton wrote: >> On 07/21/2012 16:26, antispam06 at sent.at wrote: >>> Hmm? that's an excellent question. I never formulated it this way. I >>> guess computer theft. The other possible scenarios are far less >>> probable. >> >> Still doesn't answer the question. :) What bad thing are you worried >> about happening if someone gets your keyring? > > Having a few private files opened with the key that resides on the same > hard drive unit, which I know it's a no?no. Your private key is encrypted, right? Use a strong password for that and you're in fine shape. -- If you're never wrong, you're not trying hard enough From antispam06 at sent.at Mon Jul 23 01:39:12 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Mon, 23 Jul 2012 01:39:12 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500C8BF2.70409@dougbarton.us> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> Message-ID: <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> On Sun, Jul 22, 2012, at 16:25, Doug Barton wrote: > On 07/22/2012 14:51, antispam06 at sent.at wrote: > > Having a few private files opened with the key that resides on the same > > hard drive unit, which I know it's a no?no. > > Your private key is encrypted, right? Use a strong password for that and > you're in fine shape. Yes, security through obscurity. A possible attacker won't know for sure which key is the useful one without opening the keychain. Or can he know? While we're at this one: the reason I am using KeePass is because I have a hard time remembering one strong password. Having about 50 of them, a different one for each account, it's a true pain. But a passphrase is something completely different. It's harder to type. It employs far less characters. Yet it can be looong. How about that? Is that any better? 45 ASCII lowercase with a uppercase ASCII and a couple of signs is better than 16 random alphanumerics and signs? From rjh at sixdemonbag.org Mon Jul 23 03:16:25 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 22 Jul 2012 21:16:25 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> Message-ID: <500CA5E9.7080800@sixdemonbag.org> On 7/22/2012 7:22 PM, antispam06 at sent.at wrote: > Very interesting. So having a keepass database or a gpg keychain on a > Truecrypt drive might make them both more vulnerable? "Might," sure, although for modern crypto it's quite unlikely. Far more likely is a situation where you just don't meet your goals. For instance, if you encrypt data once with a DES key and then encrypt it again with a different DES key, you might think this would be 'two layers' of crypto. In reality, there is always a third DES key which will be equivalent to encrypting with the first followed by encrypting with the second -- it's the real-world analogue of the "ROT3 followed by ROT5 is just ROT8" example I gave. The real concern here isn't making the overall system weaker: it's fooling yourself into thinking you've made the system stronger, when in reality you probably haven't. From johanw at vulcan.xs4all.nl Mon Jul 23 09:19:42 2012 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 23 Jul 2012 09:19:42 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500CA5E9.7080800@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> <500CA5E9.7080800@sixdemonbag.org> Message-ID: <500CFB0E.5020106@vulcan.xs4all.nl> On 23-07-2012 3:16, Robert J. Hansen wrote: > Far more likely is a situation where you just don't meet your goals. > For instance, if you encrypt data once with a DES key and then encrypt > it again with a different DES key, you might think this would be 'two > layers' of crypto. In reality, there is always a third DES key which > will be equivalent to encrypting with the first followed by encrypting > with the second -- it's the real-world analogue of the "ROT3 followed by > ROT5 is just ROT8" example I gave. That would be true if DES was a group, which it is not. That's why 3DES is more secure than single DES. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Mon Jul 23 09:25:46 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 Jul 2012 03:25:46 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500CFB0E.5020106@vulcan.xs4all.nl> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> <500CA5E9.7080800@sixdemonbag.org> <500CFB0E.5020106@vulcan.xs4all.nl> Message-ID: <500CFC7A.9050802@sixdemonbag.org> On 7/23/2012 3:19 AM, Johan Wevers wrote: > That would be true if DES was a group, which it is not. That's why 3DES > is more secure than single DES. D'oh. I don't know offhand which cipher I was thinking of (it's 3:30am and I'm about to hit the sack), but you're right, clearly I could not be thinking of DES. From wk at gnupg.org Mon Jul 23 10:01:25 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Jul 2012 10:01:25 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <500C5A05.5050209@budts.be> (Jeroen Budts's message of "Sun, 22 Jul 2012 21:52:37 +0200") References: <500C5A05.5050209@budts.be> Message-ID: <87r4s2hpnu.fsf@vigenere.g10code.de> On Sun, 22 Jul 2012 21:52, jeroen at budts.be said: > --enable-ssh-support option and the gpgkey2ssh script. You don't need gpgkey2ssh - it is a relict form the early days. gpg-agent supports the ssh-agent protocol for 7 years now. > Is it somehow possible to 'automatically' use my GPG subkey for SSH > session when I'm using GPG-Agent? Or am I missing something here? Install gpg-agent properly and make sure that the environment variables are set. The man page explains what you need to do. The import thing is that the envvar SSH_AUTH_SOCKET points to the right socket which is usually /home/USER/.gnupg/S.gpg-agent.ssh . You either need to put "enable-ssh-support" into the gpg-agent.conf or start gpg-agent with the option "--enable-ssh-support". You may check that it works using $ gpg-connect-agent 'getinfo ssh_socket_name' /bye D /home/USER/.gnupg/S.gpg-agent.ssh OK Now you only have to use "ssh-add" to add the keys to gpg-agent. gpg-agent will ask you for the passphrase of the ssh-key and then for a new passphrase (you may use the same) under it will be stored in GnuPG's key storage. Once this has been done, you won't need "ssh-add" anymore. You may of course use ssh-add -l to list the keys, gpg-agent knows about or ssh-add -L do show the public keys. If you have the need for finer grained control or want to disable an ssh key, you need to look at ~/.gnupg/sshcontrol . If you have a supported smartcard, an authentication key on that card will be used for ssh automagically. I am using this all of this for more than 7 years and have never looked at ssh-agent again. ECC support is not yet ready, but it is in the works. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From antispam06 at sent.at Mon Jul 23 13:21:09 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Mon, 23 Jul 2012 13:21:09 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500CA5E9.7080800@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> <500CA5E9.7080800@sixdemonbag.org> Message-ID: <1343042469.29857.140661105477533.5DE855B8@webmail.messagingengine.com> On Sun, Jul 22, 2012, at 21:16, Robert J. Hansen wrote: > The real concern here isn't making the overall system weaker: it's > fooling yourself into thinking you've made the system stronger, when in > reality you probably haven't. I don't want to make it really stronger. Just less usable for the everyday thief. I don't want something like a WEP password. I use KeePass as it is a comfortable option. It has much overhead than a plain text file, yet it's portable. I use TrueCrypt drive as an enhanced zip archive. Now, GPG, with its asymetric encryption, sounds better, but it's less portable. Altough there are more systems that have it installed than systems with TrueCrypt. In my case TrueCrypt is only a wrapper around a GPG keychain, a database and some backups. From peter at digitalbrains.com Mon Jul 23 16:25:41 2012 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 23 Jul 2012 16:25:41 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1343042469.29857.140661105477533.5DE855B8@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> <500CA5E9.7080800@sixdemonbag.org> <1343042469.29857.140661105477533.5DE855B8@webmail.messagingengine.com> Message-ID: <500D5EE5.1030703@digitalbrains.com> A different method I'd like to throw in for consideration is using a very strong random password generated by KeePass as the password to unlock your OpenPGP private key. A "password" with a lot of randomness is comparable to a symmetric encryption key when fed to GnuPG. GnuPG will still throw in extra processing with a String-To-Key conversion and a random session key, so there is some unnecessary stacking of cryptographic operations, but as long as the weakest link isn't too weak, I don't see much of a problem. [Hmmm, I must say that sounds like a rather empty statement which is vacuously true...] I'm assuming the reason for all of this is reduction of the number of difficult passphrases to remember (incidentally the precise use case of KeePass). By using a cryptographically strong password as just described, I think you get about the same effective level of security as when you store unprotected OpenPGP key material in your KeePass wallet, but at a greater convenience level. Although you probably need to turn off keyboard grabbing and such for the pinentry helper, which does reduce safety. Without turning off keyboard grabbing, you probably can't paste the password from the clipboard. HTH, Peter. PS: If you do store unprotected key material in your KeePass wallet, mind where you put it when you want it used by GnuPG. The material could be left on your hard drive depending on how you do it. -- 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 http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt From peter at digitalbrains.com Mon Jul 23 16:46:54 2012 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 23 Jul 2012 16:46:54 +0200 Subject: GPA and Windows In-Reply-To: <479955528.20120721173421@my_localhost> References: <479955528.20120721173421@my_localhost> Message-ID: <500D63DE.9030602@digitalbrains.com> On 21/07/12 18:34, MFPA wrote: > "Iff" is a widely used and recognised shorthand which means "if and only > if." Widely used and recognised, but possibly only in certain professions. Wikipedia, for example, lists it under "mathematical jargon". Computer scientists will know it as well. But it might not be as widely recognised as you think :). (don't forget the mouseover text :) 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 http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt From antispam06 at sent.at Tue Jul 24 01:45:31 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Tue, 24 Jul 2012 01:45:31 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500D5EE5.1030703@digitalbrains.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> <500CA5E9.7080800@sixdemonbag.org> <1343042469.29857.140661105477533.5DE855B8@webmail.messagingengine.com> <500D5EE5.1030703@digitalbrains.com> Message-ID: <1343087131.9748.140661105762613.31C71FA1@webmail.messagingengine.com> On Mon, Jul 23, 2012, at 16:25, Peter Lebbing wrote: > A different method I'd like to throw in for consideration is using a very > strong > random password generated by KeePass as the password to unlock your > OpenPGP > private key. Yes, that sounds a lot better than what I had in mind. It's also a way to combine the two, but with less overhead. > PS: If you do store unprotected key material in your KeePass wallet, mind > where > you put it when you want it used by GnuPG. The material could be left on > your > hard drive depending on how you do it. That's true. And that reminds me that my data on a TrueCrypt drive is still available in plain for all to access in the TEMP folder if I use unsafely designed apps, which means most of them. From expires2012 at rocketmail.com Tue Jul 24 10:33:27 2012 From: expires2012 at rocketmail.com (MFPA) Date: Tue, 24 Jul 2012 09:33:27 +0100 Subject: Is there a GnuPG command that shows the number of keys on a keyring? Message-ID: <19910348005.20120724093327@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Is there a GnuPG command to show the number of keys on a keyring? Or one which includes this as part of its output? I have looked through the gpg.man file and also at the output from gpg --dump-options for this and nothing leaps out at me. I know there are GUI frontends that show this info in their key management windows, but wondered if there is a GnuPG command to get it directly. - -- Best regards MFPA mailto:expires2012 at rocketmail.com It is easy to propose impossible remedies. -----BEGIN PGP SIGNATURE----- iQCVAwUBUA5d3aipC46tDG5pAQpztgQAjUC9Tw6/g9FFUYH26oAWnLkXyFcFLvgC Y9ZmtSz7++U+b6KvbzJWV+jE3d2fspg6JjNqxFXukJUYGpHpIX0LyFf3zjVCBTpN rfKb84yE/XKW5gd36aj9Jt2OBez2y2AAlgxxMy74F2DZrgdtIVfHuF6zxh/konGZ JCydZsXNUx8= =P/Rq -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Jul 24 10:39:04 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 24 Jul 2012 04:39:04 -0400 Subject: Is there a GnuPG command that shows the number of keys on a keyring? In-Reply-To: <19910348005.20120724093327@my_localhost> References: <19910348005.20120724093327@my_localhost> Message-ID: <500E5F28.4010802@sixdemonbag.org> On 7/24/2012 4:33 AM, MFPA wrote: > Is there a GnuPG command to show the number of keys on a keyring? On Linux, FreeBSD, OS X, etc., you can do: $ gpg2 --list-keys|grep "^pub"|wc -l From shavital at gmail.com Tue Jul 24 10:46:13 2012 From: shavital at gmail.com (Charly Avital) Date: Tue, 24 Jul 2012 04:46:13 -0400 Subject: Is there a GnuPG command that shows the number of keys on a keyring? In-Reply-To: <500E5F28.4010802@sixdemonbag.org> References: <19910348005.20120724093327@my_localhost> <500E5F28.4010802@sixdemonbag.org> Message-ID: <500E60D5.4010109@gmail.com> Robert J. Hansen <500E5F28.4010802 at sixdemonbag.org> July 24, 2012 4:43:58 AM wrote: > On Linux, FreeBSD, OS X, etc., you can do: > > $ gpg2 --list-keys|grep "^pub"|wc -l I've got 1618, some serious and urgent cleaning is required. Thank you Robert. Charly From wk at gnupg.org Tue Jul 24 12:37:24 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Jul 2012 12:37:24 +0200 Subject: Is there a GnuPG command that shows the number of keys on a keyring? In-Reply-To: <500E5F28.4010802@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 24 Jul 2012 04:39:04 -0400") References: <19910348005.20120724093327@my_localhost> <500E5F28.4010802@sixdemonbag.org> Message-ID: <87hasxe97f.fsf@vigenere.g10code.de> On Tue, 24 Jul 2012 10:39, rjh at sixdemonbag.org said: > $ gpg2 --list-keys|grep "^pub"|wc -l In case you want to put this into a HOWTO, you better write: gpg2 --with-colons --list-keys|grep "^pub:"|wc -l As usual this also works with gpg. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vedaal at nym.hush.com Tue Jul 24 15:58:08 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 24 Jul 2012 09:58:08 -0400 Subject: asymmetry of 'adduid' and 'deluid' Message-ID: <20120724135809.9BDE76F442@smtp.hushmail.com> Recently added a uid and deleted a uid to one of my keys. Found that to add a uid, gnupg asks for the passphrase, but to delete a uid, it does not. (Doesn't really matter much, since the secret key is required for both, but was curious if there is any underlying reason why gnupg does it this way.) vedaal From dkg at fifthhorseman.net Tue Jul 24 16:08:10 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Jul 2012 10:08:10 -0400 Subject: asymmetry of 'adduid' and 'deluid' In-Reply-To: <20120724135809.9BDE76F442@smtp.hushmail.com> References: <20120724135809.9BDE76F442@smtp.hushmail.com> Message-ID: <500EAC4A.6030701@fifthhorseman.net> On 07/24/2012 09:58 AM, vedaal at nym.hush.com wrote: > Recently added a uid and deleted a uid to one of my keys. > > Found that to add a uid, gnupg asks for the passphrase, but to > delete a uid, it does not. > > (Doesn't really matter much, since the secret key is required for > both, > but was curious if there is any underlying reason why gnupg does it > this way.) possession of the secret key is not required for deluid, actually. look at it this way: deluid is just an edit of your local keyring -- it removes a handful of packets (note that if the key is already on the public keyservers or someone else has a copy, they will still have the user ID that you deleted). adduid, on the other hand, requires the creation of a new cryptographic signature: the self-sig made by the primary key over the user ID. To create this self-sig, gpg needs access to the secret key material for the associated primary key. make sense? hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue Jul 24 16:10:09 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 24 Jul 2012 10:10:09 -0400 Subject: asymmetry of 'adduid' and 'deluid' In-Reply-To: <20120724135809.9BDE76F442@smtp.hushmail.com> References: <20120724135809.9BDE76F442@smtp.hushmail.com> Message-ID: On Jul 24, 2012, at 9:58 AM, vedaal at nym.hush.com wrote: > Recently added a uid and deleted a uid to one of my keys. > > Found that to add a uid, gnupg asks for the passphrase, but to > delete a uid, it does not. > > (Doesn't really matter much, since the secret key is required for > both, > but was curious if there is any underlying reason why gnupg does it > this way.) To add a UID, GnuPG needs to generate a binding signature from the primary key. To generate a signature, we of course need the passphrase. To delete a UID, GnuPG just needs to throw away packets. No signature needed, so no passphrase needed. Note that to revoke (rather than delete) a UID involves making a signature as well, and will also require a signature. David From vedaal at nym.hush.com Tue Jul 24 16:11:29 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 24 Jul 2012 10:11:29 -0400 Subject: asymmetry of 'adduid' and 'deluid' // my mistake, sorry ;-( Message-ID: <20120724141129.9AEFD6F442@smtp.hushmail.com> 'Doesn't really matter much, since the secret key is required for both,' sorry, my mistake, to remove a uid, doesn't require the secret key, (probably done this way to maken it easier for users to manage their public keyrings) vedaal From wk at gnupg.org Tue Jul 24 16:15:51 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Jul 2012 16:15:51 +0200 Subject: asymmetry of 'adduid' and 'deluid' In-Reply-To: <20120724135809.9BDE76F442@smtp.hushmail.com> (vedaal@nym.hush.com's message of "Tue, 24 Jul 2012 09:58:08 -0400") References: <20120724135809.9BDE76F442@smtp.hushmail.com> Message-ID: <878ve9dz3c.fsf@vigenere.g10code.de> On Tue, 24 Jul 2012 15:58, vedaal at nym.hush.com said: > Found that to add a uid, gnupg asks for the passphrase, but to > delete a uid, it does not. For ?adduid? we need to a create a user-id binding signature (self-signature) and thus need the secret key and in turn the passphrase. ?deluid? simply removes the user-id, its self-signature, and its key signatures. No need for any crypto operations. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Tue Jul 24 19:41:20 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Jul 2012 13:41:20 -0400 Subject: charset weirdness with non-ascii User IDs Message-ID: <87k3xtf45b.fsf@pip.fifthhorseman.net> Hi folks-- i'm seeing some strange behavior with the keyservers on GNU/Linux systems that don't have a UTF-8 locale, or when LANG is set to something non-UTF8: 0 dkg at pip:~$ LANG=C gpg --keyserver keys.mayfirst.org --search '=Andrew Lee (? ??) ' gpg: searching for "=Andrew Lee (?????) " from hkp server keys.mayfirst.org (1) Andrew Lee Andrew Lee (\xe6\x9d\x8e\xe5\x81\xa5\xe7\xa7\x8b) Andrew Lee (\xe6\x9d\x8e\xe5\x81\xa5\xe7\xa7\x8b) 1024 bit DSA key 0xB6250985, created: 2004-11-02 Keys 1-1 of 1 for "=Andrew Lee (???) ". Enter number(s), N)ext, or Q)uit > q 0 dkg at pip:~$ LANG=C gpg --keyserver keys.mayfirst.org --search '=Antoine Beaupr? (work) '' gpg: searching for "=Antoine Beaupr?? (work) " from hkp server keys.mayfirst.org gpg: key "=Antoine Beaupr? (work) " not found on keyserver 0 dkg at pip:~$ Note that the --search for Andrew's UTF-8 User ID succeeds, but Antoine's fails. This behavior happens on both gpg 1.4.12 and 2.0.19, and it happens with or without debian's gnupg-curl packages installed. Given that User IDs must be UTF-8-encoded, i'm not sure what the right thing to do is here. I tried searching for this bug on https://bugs.g10code.com, but i'm getting an error when i search for the term "charset" for some reason. Any suggestions for the right direction for a fix? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From expires2012 at rocketmail.com Tue Jul 24 20:02:14 2012 From: expires2012 at rocketmail.com (MFPA) Date: Tue, 24 Jul 2012 19:02:14 +0100 Subject: Is there a GnuPG command that shows the number of keys on a keyring? In-Reply-To: <500E5F28.4010802@sixdemonbag.org> References: <19910348005.20120724093327@my_localhost> <500E5F28.4010802@sixdemonbag.org> Message-ID: <698862097.20120724190214@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 24 July 2012 at 9:39:04 AM, in , Robert J. Hansen wrote: > On 7/24/2012 4:33 AM, MFPA wrote: >> Is there a GnuPG command to show the number of keys on a keyring? > On Linux, FreeBSD, OS X, etc., you can do: > $ gpg2 --list-keys|grep "^pub"|wc -l Thanks Rob. On PGPNET I was also given the answer "gpg --export -a|gpg --import" which gives me an answer more directly on Windows than your way does. - -- Best regards MFPA mailto:expires2012 at rocketmail.com There is no job so simple that it cannot be done wrong -----BEGIN PGP SIGNATURE----- iQCVAwUBUA7jLKipC46tDG5pAQpLcAP/f2DqzLiwI0er24yTk0X24xs5a9M6098m 3U1ZtTF5QyIKkz2d8Ua1zUn92nZBR6dp2RIYmkp55JHzN54O+pYYRpbMJbbeHz8i Yvs1ilydqWMX5vR0DYkFGv4pveSJdSfX2uOVLxjlUhVYQdZajJE5oUpi8dwhACV2 T06oKhivw8c= =JC0U -----END PGP SIGNATURE----- From jeroen at budts.be Tue Jul 24 22:04:31 2012 From: jeroen at budts.be (Jeroen Budts) Date: Tue, 24 Jul 2012 22:04:31 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <87r4s2hpnu.fsf@vigenere.g10code.de> References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> Message-ID: <500EFFCF.3070206@budts.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/23/2012 10:01 AM, Werner Koch wrote: > On Sun, 22 Jul 2012 21:52, jeroen at budts.be said: > >> Is it somehow possible to 'automatically' use my GPG subkey for >> SSH session when I'm using GPG-Agent? Or am I missing something >> here? > > Install gpg-agent properly and make sure that the environment > variables are set. The man page explains what you need to do. > The import thing is that the envvar SSH_AUTH_SOCKET points to the > right socket which is usually /home/USER/.gnupg/S.gpg-agent.ssh . > You either need to put "enable-ssh-support" into the gpg-agent.conf > or start gpg-agent with the option "--enable-ssh-support". You > may check that it works using > > $ gpg-connect-agent 'getinfo ssh_socket_name' /bye D > /home/USER/.gnupg/S.gpg-agent.ssh OK Aha, OK, when I tried to run that command I got an error (telling me that that functionality was not implemented). While I followed instructions to disable the gpg and ssh parts of gnome-keyring, apparently they didn't work. Now I completely disabled 'Launch GNOME services on startup' in XFCE so gnome-keyring is not started anymore. Now I get the correct output from the above command. > Now you only have to use "ssh-add" to add the keys to gpg-agent. > gpg-agent will ask you for the passphrase of the ssh-key and then > for a new passphrase (you may use the same) under it will be stored > in GnuPG's key storage. Once this has been done, you won't need > "ssh-add" anymore. This works correctly as well now. I added my SSH key, gpg-agent prompted me for the passphrase of the SSH-key and asked me for a new passphrase. Now I can indeed log-in into my server without having to ssh-add my key. However, before I started all this I could do this as well, as gnome-keyring automatically does an ssh-add for you. (or as I understand it, gnome-keyring uses it's own ssh-agent which unlocks the key only when it is needed and automatically prompts for the passphrase at that moment.) >> --enable-ssh-support option and the gpgkey2ssh script. > > You don't need gpgkey2ssh - it is a relict form the early days. > gpg-agent supports the ssh-agent protocol for 7 years now. What I really wanted to accomplish here is to use my GPG authentication subkey for SSH authentication, without having to use an SSH-key at all. But it is still not clear to me how this can be accomplished, if possible at all? I was thinking that: 1) somehow I should be able to make my public Authentication key known to the server. That's why I used `gpgkey2ssh ` and added the output to ~/.ssh/authorized_keys on the server. 2) somehow gpg-agent would also try authentication subkeys on GPG-keys, amongst any other known SSH-keys, when trying to find the correct key to authenticate to SSH? This doesn't seem to be the case. Ideally I would be able to always use my GPG Authentication subkey for SSH authentication and would not need any other SSH-specific key. Is something like this possible, or am I completely missing the point? (I still need to learn a lot about SSH etc). Thanks for your reply! Jeroen - -- website: http://budts.be/ - twitter: @teranex ___________________________________ Registered Linux User #482240 - GetFirefox.com - ubuntu.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCAAGBQJQDv/PAAoJEBrqc/v4ufiMclAP/jodfRWcH5useZmobhBKR9kp RYZ+W0Yd3Ph65fQQA+FTJVUaUBFQsQFnbFAjB9vfrVFl3Ww02VeTC1xb7SMQePfC 5MJl4geFA+Y8/z2QTeSBvM9e2UrkOGxRi0ISBOAmPm0b25uIyTDr+I4+kxz55VrS 3XZs2rn7DA0/IUN05a9M8eGnN77UmQvyAHaOo/08kFa0W+F+jTi2yKocxcz7Jqfm kAkxScvhLXI193utWk2XFhSycVXgN8aAht9Lhvdtptps/Nyi3OOxqM029PVunASa BfAFYBBbAQsM1EnlgwNJ//m2RbxgbCL0Aw7NR+yvlBvmL+yc32FNEPltlylUk6On nm1erwmTF30JH6mi9DQTLZgXha66BByHLkXqP6YouIfuJlvdSiL+ekh9dz0g3OJF FOioBAAGNjQ2PsxBFZL6rxSUfxnfFmdy+Fg8to8+57DGayrkmF0tVwnVwOWlmAjz wPOosBo/C3PA0ZOGkE3EWuzKYbduhjCN2pNLwaOHAytgSfRRfUon8ghDP730I9R7 xL3X1XNxMo0OLqY0mpH3pCoYsoTOoXawjIlL7piE0roASrGXSfVze8+SxWAdSgzJ Jbcd6mEtcwkfTleX2eM2unKCr6bG4jccwRQda1be6l07X8EUsd6YHSfL8CUVdqU0 JjDVWtT9spLvLqmXe/kD =mXMV -----END PGP SIGNATURE----- From faramir.cl at gmail.com Wed Jul 25 03:23:04 2012 From: faramir.cl at gmail.com (Faramir) Date: Tue, 24 Jul 2012 21:23:04 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> Message-ID: <500F4A78.4050301@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 22-07-2012 19:39, antispam06 at sent.at escribi?: > On Sun, Jul 22, 2012, at 16:25, Doug Barton wrote: ... >> Your private key is encrypted, right? Use a strong password for >> that and you're in fine shape. > > Yes, security through obscurity. A possible attacker won't know for > sure which key is the useful one without opening the keychain. Or > can he know? I don't know why do you say security through obscurity. Private keys can be stored encrypted, so even if somebody steal them, the thieve can't use them. That is security through encryption. A hacker will know what key he needs to open a file, because the encrypted file say it, unless the sender selects hide recipient's key or something like that. By default, the file say the ID of the key required to decrypt it. But that is a different thing, and has nothing to do with storing the keyring inside a Keepass database. > While we're at this one: the reason I am using KeePass is because I > have a hard time remembering one strong password. Having about 50 > of them, a different one for each account, it's a true pain. But a > passphrase is something completely different. It's harder to type. > It employs far less characters. Yet it can be looong. How about > that? Is that any better? 45 ASCII lowercase with a uppercase ASCII > and a couple of signs is better than 16 random alphanumerics and > signs? I bet it is, as long as that 45 characters passphrase is not something that could be found on dictionaries, or combining dictionary words. But probably it is an overkill. Anyway, Keepass has a built in password strength estimator, measured in bits. I don't know what is the criteria to measure the strength, but I know it is not only based on the characters used, it also include the order used (once I was testing it, and swaped 2 characters, and the strength increased). If your password's strength is 128 bits or more, it won't be feasible to bruteforce it (probably the infeasible level is reached with less bits too, but I don't know where is the limit). Of course, if it is vulnerable to dictionary attacks, then you are toasted. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQD0p4AAoJEMV4f6PvczxAKdcIAITDNgsKy+SVzBdouq/RIsb/ VEfFthC7z+kOjTNXVTFNbZfkNsDNAJTwntYggAN8xyH5HaygjFXJBFdBFj4f6E8c 4tjS9yc1Qi1c+xPRPTMowRmLgPp06EZba+im11+APZ/plv5/I+FdyY74XEJojfRg aQqy0SvsQlmdeoc9MVMW/F/uXxuywVcws4KsytH+AHq4CiL/BmJWj8kS3eX9gu1f 4/SjhbJ2I09tf9rBbm2+vtAuY7kpmcgm2h+Lkhn0I2az0MggBUeZvODkTD7iNOOC kgAQqCqvJe+mt8qm0VLoyK5hKPcahLElOombJBrmXwXIhfNvDL/6qhsQXpA4geU= =HlJ9 -----END PGP SIGNATURE----- From faramir.cl at gmail.com Wed Jul 25 04:21:36 2012 From: faramir.cl at gmail.com (Faramir) Date: Tue, 24 Jul 2012 22:21:36 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500C681C.2020201@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> Message-ID: <500F5830.4080808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 22-07-2012 16:52, Robert J. Hansen escribi?: > On 7/22/2012 12:12 PM, Faramir wrote: >> If your secret key is password protected, placing it inside a >> keepass file would add a second (maybe unneeded) layer of >> protection, and you can chose a different encryption algorithm >> than GnuPG uses, so if one algo gets broken, the other would >> hold. > > Not necessarily. This idea of 'stacking algorithms improves > strength' is tempting, but it can just as easily reduce strength or > do nothing. Clearly I'm out of my league there. I had heard about that, but later I also heard about stacking different algos (with different keys of course) to increase security. > Cryptography is a subtle art, and algorithms interact with each > other in deeply surprising and counterintuitive ways. Before > advocating that algorithms be composed together to achieve certain > results, it's good to make sure that these compositions are > cryptanalytically sound. :) Indeed. But, AFAIK (and I can be wrong), private keys are stored individually encrypted (lets assume the use encrypts them all) inside the private keyring. Each one can have a different passphrase. Then you take that keyring and encrypt it using... lets say, Twofish algo, with a different passphrase. In that case, you would be encrypting a different file, not the individual private key, so it might be at least equivalent to using salt to make the file change. Anyway, do you know about any list of "compatible" encryption algorithms? I mean, pairs that work well together. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQD1gwAAoJEMV4f6PvczxA2AcH/jyAJrSpwCK838pg0j3omJ7H zVZElXU4zh8r8PNCaO4SsRdkyNRWmvlzN5/nMkbl80RFzEgiWN/IZEcnPxtbkiMV 2XoIyoF3rYGnLj/SvSUsyMBudo5UJDl0iBUu2e6UEfLQEKPiF/C7usjCq/y+n0Yc J/7q9ZoW8WY4Sehvmk9xVPi4WmEKx4Z4it6UAW2oDH9BUmbL565nGalRQVHve0qC 9c9siNkvj73HgkHgHCRDt+PKzcJe7U/nJYPLslgc0Rki/siytvQlHUpqGgWxuJQF ykOyWGUIM2shHiCWUCNUKSDvkaUwb+1/+Jgsn8P6kemQpSzrYBLEF0b1oZNNF3o= =zpYk -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Jul 25 07:12:45 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 25 Jul 2012 01:12:45 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500F5830.4080808@gmail.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <500F5830.4080808@gmail.com> Message-ID: <500F804D.7070107@sixdemonbag.org> On 7/24/2012 10:21 PM, Faramir wrote: > Clearly I'm out of my league there. I had heard about that, but later > I also heard about stacking different algos (with different keys of > course) to increase security. I'm unaware of any reputable reference that recommends this practice. That's not to say no such reference exists, only that if one exists I'm unaware of it. > Anyway, do you know about any list of "compatible" encryption > algorithms? I mean, pairs that work well together. The better question, to me at least, is "why would I want to do this?" Cryptosystems tend to fail predominantly due to human error, then to software bugs. Consider that since PGP 2.6 was released in ... what was it, '91? ... not one single encryption algorithm used by PGP has ever been broken. Although IDEA is not well-regarded by modern standards it's still a safe cipher; and RSA is still, well, RSA. If the algorithms are unlikely to be broken but the likelihood of security-impacting software bugs is essentially certain, then stacking algorithms would seem to be ill-advised. Stacking algorithms increases the complexity of the code, increases the number of keys which must be managed, and so forth. Rather than enhancing security, my suspicion would be that it diminishes it by increasing the complexity of the system. From htd at fritha.org Wed Jul 25 08:51:26 2012 From: htd at fritha.org (Heinz Diehl) Date: Wed, 25 Jul 2012 08:51:26 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500F5830.4080808@gmail.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <500F5830.4080808@gmail.com> Message-ID: <20120725065126.GB2625@fritha.org> On 25.07.2012, Faramir wrote: > Clearly I'm out of my league there. I had heard about that, but > later I also heard about stacking different algos (with different > keys > of course) to increase security. What's the model of threat in your case, actually? Usually, the crypto algorithm isn't the weakest part in the whole scenario, and stacking different algorithms will therefore not make any sense at all. From mika.henrik.mainio at hotmail.com Wed Jul 25 09:56:41 2012 From: mika.henrik.mainio at hotmail.com (Mika Suomalainen) Date: Wed, 25 Jul 2012 10:56:41 +0300 Subject: Is there a GnuPG command that shows the number of keys on a keyring? In-Reply-To: <87hasxe97f.fsf@vigenere.g10code.de> References: <19910348005.20120724093327@my_localhost> <500E5F28.4010802@sixdemonbag.org> <87hasxe97f.fsf@vigenere.g10code.de> Message-ID: <500FA6B9.8070708@hotmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 24.07.2012 13:37, Werner Koch wrote: > On Tue, 24 Jul 2012 10:39, rjh at sixdemonbag.org said: > >>> $ gpg2 --list-keys|grep "^pub"|wc -l > In case you want to put this into a HOWTO, you better write: > > gpg2 --with-colons --list-keys|grep "^pub:"|wc -l > > As usual this also works with gpg. There is also gpg --export -a|gpg --import but that takes time depending on how many keys there are in keyring. ``` gpg: Total number processed: 309 gpg: unchanged: 309 ``` - -- Mika Suomalainen NOTICE! I am on mobile broadband with very limited time, so I cannot read emails very much. The best time to contact me is probably weekends when I have better connectivity with good luck. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Public key: http://mkaysi.github.com/PGP/key.txt Comment: Fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728 Comment: Why do I (clear)sign emails? http://git.io/6FLzWg Comment: Please remove PGP lines in replies. http://git.io/nvHrDg Comment: Charset of this message should be UTF-8. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJQD6a2AAoJEE21PP6CpGcoqZ4P/0MXXKo+uck3fR9f8DukO5fr Xf1BamQ6bWXWgnjOYbhfh7fOR22EbRdVadJfpFJLToqr0ubMw26x4r6jYPbA5Tg6 Z9ZLWbMzGnZOlzAxQmpNcMiIbnxdy3/hT+mVcHA0f3SrosSDJ76KxVr+R1hxjrsF bxmZi6uUdgwK7c90Ajp7ncjkbZJ1qImQl76uBiBNgUznXz901MkYwLWF/9cAKzee U8pIZKT5JTqG5c4LlCPUcX7nznVKcrZD1yuOi5guIZQdw0WGzGzTRdqlvJdYAEsw pEtlntaXFTTZT7FkTAOePiP3YxfjTCz5y/f1PXXqg1CJKWU+AGjc/YzF44pB0Ugc oBw7+hJi7dMlNU1+pqB3haZAdkONbYLIM6EU1ifdA3Wbq3LsqinLbB0GRXVsevFZ MCder2fD5W9jEPQdfkRwvhGh44CLGwRlycN2spn0snsPi1GcDdIasNoZe90ubxNa pDnhWmxb+osD7pJyBe7JkczP3M3IADMHDDdwlUdq5TD1xu8x6pnXx832+LiTiUOm YEN1gOoRnHergqeEVBBdXNP7HyS42d7JDj6MN456W187NH5Tyl90ERMKkOXp5bGG 9QzSYg1Z7HA6plzLBpXQUbqZFTbQEHbq5x9LFW48YsdxiKs8eCz5vARu9KDJBGQ3 R7I5+KsHTlCO57RcYpBX =dROO -----END PGP SIGNATURE----- From mika.henrik.mainio at hotmail.com Wed Jul 25 10:07:50 2012 From: mika.henrik.mainio at hotmail.com (Mika Suomalainen) Date: Wed, 25 Jul 2012 11:07:50 +0300 Subject: asymmetry of 'adduid' and 'deluid' In-Reply-To: <20120724135809.9BDE76F442@smtp.hushmail.com> References: <20120724135809.9BDE76F442@smtp.hushmail.com> Message-ID: <500FA956.4050700@hotmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 24.07.2012 16:58, vedaal at nym.hush.com wrote: > Recently added a uid and deleted a uid to one of my keys. > > Found that to add a uid, gnupg asks for the passphrase, but to > delete a uid, it does not. > > (Doesn't really matter much, since the secret key is required for > both, but was curious if there is any underlying reason why gnupg > does it this way.) I'm not sure, but this might be because deleting uid isn't permanent if you sync the key from keyserver. 1. Create UID. 2. Push key to keyserver. 3. Delete UID. 4. Get key from keyserver. 5. The deleted UID appears. You should use command revuid, if you want to revoke UID. - -- Mika Suomalainen NOTICE! I am on mobile broadband with very limited time, so I cannot read emails very much. The best time to contact me is probably weekends when I have better connectivity with good luck. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Public key: http://mkaysi.github.com/PGP/key.txt Comment: Fingerprint = 24BC 1573 B8EE D666 D10A AA65 4DB5 3CFE 82A4 6728 Comment: Why do I (clear)sign emails? http://git.io/6FLzWg Comment: Please remove PGP lines in replies. http://git.io/nvHrDg Comment: Charset of this message should be UTF-8. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJQD6lSAAoJEE21PP6CpGcolsYP/jvQ/OmQ2HqekfnUWPe+kHU5 h3FGdH1zLAQXq5mm41GpNi2ClnDHjridH4cbwHMlB+36SLcxHyHXMCX/Has6r0+z AIPlT9hkhe840w2tnFdZIgXPgoz4rNEZ2YV+TUWxjTm/Rs8ViIObtU66zyCe36a+ VoMKpMHmrGcAQdLw1JGWVAOYtGaHcz5xhdMAZoT935t3O7irdnlO3nmabMMUcLXV 8BdPAXCQdaUSUNbui3riLwMUC449Jx8hbM2hLNK21iOIZclVz9Wf0TLo1PhEh0TC UK/cyHos29DGm8oVEhlwTxh6m58uzAI7mAU3yOPPPKw5TzFJwNSzOW3QRZhWD16D iH6WaLOViHC+4ipZurac+6cTbHeWSAm4NV6AC/OZPkvCOCgP+gDERtAZJn+wbBBm jyPmcVWRpppF2pAs+NMytNO2mD2HPO88X4F09msALKx5IKxWzobiv+wnbQnAI/q4 kMW8O3IVn+qg4+Jhylg7J++CdvCvdr9tAhwQigntNgzmidSZTJjwKCGpmprPkpTX Yw44qymelrhx0SObjjjsrh7wX6YcENuGOsldqtjQRUD8RjAPtqe6ULsYDuCa3ZKC ZOJwjbcTVYBtqC//lPHyGhWufxCq67lpQ1MNyBUF1s4pONKOuScJc3dOu3QuAGM+ sM5vXEhK2uDAaATovvtT =MMai -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jul 25 12:04:44 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Jul 2012 12:04:44 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <500EFFCF.3070206@budts.be> (Jeroen Budts's message of "Tue, 24 Jul 2012 22:04:31 +0200") References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> <500EFFCF.3070206@budts.be> Message-ID: <87txwwcfz4.fsf@vigenere.g10code.de> On Tue, 24 Jul 2012 22:04, jeroen at budts.be said: > apparently they didn't work. Now I completely disabled 'Launch GNOME > services on startup' in XFCE so gnome-keyring is not started anymore. > Now I get the correct output from the above command. Please complain on the xfce and gnome lists and tell them they should stop hijacking gpg-agent - at least by default. > What I really wanted to accomplish here is to use my GPG > authentication subkey for SSH authentication, without having to use an > SSH-key at all. But it is still not clear to me how this can be > accomplished, if possible at all? With 2.1-betaX it is easy to do. With older version you need probably need to use gpgkey2ssh. But the latter is not weel documented and frankly I have not used it at all. In case you can use 2.1-beta, here what I would do: $ gpg2 --with-keygrip -k 1E42B367 pub 2048D/1E42B367 2007-12-31 [expires: 2018-12-31] Keygrip = 44B9E7E287B11C0E033A1A93ECCFDBC6AF7CCFAE uid Werner Koch sub 1024D/77F95F95 2011-11-02 Keygrip = D11C82133CAADCA42A00074D5EE92023B85110DF sub 2048R/C193565B 2011-11-07 [expires: 2013-12-31] Keygrip = 52A831E2CCCD992BCA0D3082B1D945DA5451BE50 Now assuming 77F95F95 would be an authenticaion key, you run a echo "D11C82133CAADCA42A00074D5EE92023B85110DF 0" >>~/.gnupg/sshcontrol and you are done. The point with 2.1 is that it stored the key material independent from the protocol and thus you may use as you like. gpg-agent does not need gpg to work with this subkey. When migrating to 2.1 (see the README) gpg transfers the key material to gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marco+gnupg at websource.ch Wed Jul 25 13:49:35 2012 From: marco+gnupg at websource.ch (Marco Steinacher) Date: Wed, 25 Jul 2012 13:49:35 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <87txwwcfz4.fsf@vigenere.g10code.de> References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> <500EFFCF.3070206@budts.be> <87txwwcfz4.fsf@vigenere.g10code.de> Message-ID: <500FDD4F.9030503@websource.ch> On 25.07.2012 12:04, Werner Koch wrote: > On Tue, 24 Jul 2012 22:04, jeroen at budts.be said: >> What I really wanted to accomplish here is to use my GPG >> authentication subkey for SSH authentication, without having to use an >> SSH-key at all. But it is still not clear to me how this can be >> accomplished, if possible at all? > > With 2.1-betaX it is easy to do. With older version you need probably > need to use gpgkey2ssh. But the latter is not weel documented and > frankly I have not used it at all. > > In case you can use 2.1-beta, here what I would do: > > $ gpg2 --with-keygrip -k 1E42B367 > pub 2048D/1E42B367 2007-12-31 [expires: 2018-12-31] > Keygrip = 44B9E7E287B11C0E033A1A93ECCFDBC6AF7CCFAE > uid Werner Koch > sub 1024D/77F95F95 2011-11-02 > Keygrip = D11C82133CAADCA42A00074D5EE92023B85110DF > sub 2048R/C193565B 2011-11-07 [expires: 2013-12-31] > Keygrip = 52A831E2CCCD992BCA0D3082B1D945DA5451BE50 > > Now assuming 77F95F95 would be an authenticaion key, you run a > > echo "D11C82133CAADCA42A00074D5EE92023B85110DF 0" >>~/.gnupg/sshcontrol > > and you are done. I think 'monkeysphere subkey-to-ssh-agent' will do the same with GnuPG versions before 2.1. See http://lists.gnupg.org/pipermail/gnupg-users/2009-July/036946.html It will extract the keygrip of your authentication subkey and add it to sshcontrol. Then you can use 'ssh-add -L' to get the public part of your auth key and add it to the .authorized_keys file on your server. HTH Marco -- OpenPGP Key ID: 0x62937F7F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From antispam06 at sent.at Wed Jul 25 14:29:32 2012 From: antispam06 at sent.at (antispam06 at sent.at) Date: Wed, 25 Jul 2012 14:29:32 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500F4A78.4050301@gmail.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> <500F4A78.4050301@gmail.com> Message-ID: <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> On Wed, Jul 25, 2012, at 03:23, Faramir wrote: > El 22-07-2012 19:39, antispam06 at sent.at escribi?: > > On Sun, Jul 22, 2012, at 16:25, Doug Barton wrote: > ... > >> Your private key is encrypted, right? Use a strong password for > >> that and you're in fine shape. > > > > Yes, security through obscurity. A possible attacker won't know for > > sure which key is the useful one without opening the keychain. Or > > can he know? > > I don't know why do you say security through obscurity. Private keys > can be stored encrypted, so even if somebody steal them, the thieve > can't use them. That is security through encryption. I keep the key on the same phisical drive as the encrypted document. That's security through obscurity assuming the other one won't know where to search for the key, which is not stored with the right extension or in the most common place. > A hacker will know what key he needs to open a file, because the > encrypted file say it, unless the sender selects hide recipient's key > or something like that. By default, the file say the ID of the key > required to decrypt it. But that is a different thing, and has nothing > to do with storing the keyring inside a Keepass database. So he or she will have to locate the right key. Reasonable would be to keep the key away, at least on some removable media. > > While we're at this one: the reason I am using KeePass is because I > > have a hard time remembering one strong password. Having about 50 > > of them, a different one for each account, it's a true pain. But a > > passphrase is something completely different. It's harder to type. > > It employs far less characters. Yet it can be looong. How about > > that? Is that any better? 45 ASCII lowercase with a uppercase ASCII > > and a couple of signs is better than 16 random alphanumerics and > > signs? > > I bet it is, as long as that 45 characters passphrase is not > something that could be found on dictionaries, or combining dictionary > words. But probably it is an overkill. Anyway, Keepass has a built in > password strength estimator, measured in bits. I don't know what is > the criteria to measure the strength, but I know it is not only based > on the characters used, it also include the order used (once I was > testing it, and swaped 2 characters, and the strength increased). If > your password's strength is 128 bits or more, it won't be feasible to > bruteforce it (probably the infeasible level is reached with less bits > too, but I don't know where is the limit). Of course, if it is > vulnerable to dictionary attacks, then you are toasted. If only dictionary attacks would be the the problem than any longish verse from a popular band could do it. Just add a comma in some weird place and you have broken even the lyrics hacker. From vedaal at nym.hush.com Wed Jul 25 17:01:27 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 25 Jul 2012 11:01:27 -0400 Subject: forward slash vs backward slash on ordinary (non-MSYS, non-Cygwin) windows commandline Message-ID: <20120725150127.7639C6F448@smtp.hushmail.com> MFPA and Mika wrote that an option to know how many keys there are on a keyring would be to use: gpg --export -a|gpg --import and Rob suggested (for linux systems) : gpg2 --list-keys|grep "^pub"|wc -l Both of these work on windows using either the Cygwin or MSys commandlines, but for the ordinary windows dos box, which doesn't allow pipes, the following works: gpg --import c:/gnupg/pubring.gpg (assuming that the keyring is in the c:\gnupg\home directory) BUT it works ONLY if the forward slash is used. If the backward slash is used, then gnupg gives an error that it can't find the directory. Here is the gnupg output gpg --import C:\gnupg\home\pubring.gpg gpg: can't open `C:gnupg\pubring.gpg': No such file or directory gpg: Total number processed: 0 Under what circumstances does gnupg on windows, require the forward slash? (not a big deal, as gnupg does give an error message that the directory can't be found, and that can be taken as an indication to use a forward slash rather than a backward slash) maybe this could be added to the documentation or the FAQ ? vedaal From jw72253 at verizon.net Wed Jul 25 17:02:14 2012 From: jw72253 at verizon.net (John) Date: Wed, 25 Jul 2012 10:02:14 -0500 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com><500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <1342999379.11048.140661105298461.7A51A173@webmail.messagingengine.com> Message-ID: Hello. I use both too, but I do so mainly due to the convenience it provides without apparently introducing additional weakness to my system. I put the key names, not the actual code with the keys themselves, into the Keepass database so that I can have handy access to the passwords for them. All of these entries are protected by a master password, no less so than as they were when stored in a file, but much more accessible. From vedaal at nym.hush.com Wed Jul 25 18:14:26 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 25 Jul 2012 12:14:26 -0400 Subject: windows command line // my mistake Message-ID: <20120725161426.E2A796F448@smtp.hushmail.com> >but for the ordinary windows dos box, which doesn't allow pipes, sorry, my mistake :-(( current windows does allow pipe, but not grep vedaal From juice.qr at gmail.com Wed Jul 25 16:37:54 2012 From: juice.qr at gmail.com (Chris Clifton) Date: Wed, 25 Jul 2012 10:37:54 -0400 Subject: old vs new gnupg - encrypting files Message-ID: Hi, I have a problem with encrypting some text files with gpg, We recently upgraded our old encrypt/decrypt server (old 32 bit rhel4 box) to a new amazon linux 64 bit server on aws. I moved the gpg keyring to the new server and can encrypt files just fine with the keys on the public keyring, no problems. We have one public key however that the end user (that we send the encrypted files to) is saying they can't decrypt when we encrypt with their key on the new server. I've tried encrypting the same file (md5sum matches) on the old server and new server, and the encrypted file size differs by 1 or 2 bytes on the new server. As expected, the md5sums of the encrypted file on old and new server also don't match. I thought the problem might have something to do with how the new server doesn't have ELG-E in its cipher list, only ELG, but another person has since told me that shouldn't matter. key details on new server, ######################## pub 1024D/96765440 created: 1998-10-06 expires: never usage: SCA trust: ultimate validity: ultimate sub 2048g/0840DAA8 created: 1998-10-06 expires: never usage: E [ultimate] (1). XYZ Corp (XYZ) gpg> showpref [ultimate] (1). XYZ Corp (XYZ) Cipher: CAST5, 3DES, [1] Digest: SHA1 Compression: ZIP, Uncompressed ######################## key details on old server, ######################## pub 1024D/96765440 created: 1998-10-06 expires: never trust: u/u sub 2048g/0840DAA8 created: 1998-10-06 expires: never (1). XYZ Corp (XYZ) Command> showpref pub 1024D/96765440 created: 1998-10-06 expires: never trust: u/u (1). XYZ Corp (XYZ) Cipher: CAST5, 3DES, [1] Digest: SHA1 Compression: ZIP, Uncompressed ####################### ######################## Old server gpg --version: -bash-3.00$ gpg --version gpg (GnuPG) 1.2.6 Copyright (C) 2004 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ######################## New server gpg --version: -bash-4.1$ gpg --version gpg (GnuPG) 2.0.18 libgcrypt 1.4.5 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 Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Wed Jul 25 18:33:08 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 25 Jul 2012 18:33:08 +0200 Subject: old vs new gnupg - encrypting files In-Reply-To: References: Message-ID: <6933845.2Dk9xnJhG5@inno> Am Mi 25.07.2012, 10:37:54 schrieb Chris Clifton: > I moved the gpg keyring to the new server and can encrypt files just fine > with the keys on the public keyring, no problems. We have one public key > however that the end user (that we send the encrypted files to) is saying > they can't decrypt when we encrypt with their key on the new server. Have you tried encrypting the file to the other one and your own key simultaneously? That might allow a better comparison of the difference between the two systems. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Jul 25 18:48:03 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Jul 2012 18:48:03 +0200 Subject: windows command line // my mistake In-Reply-To: <20120725161426.E2A796F448@smtp.hushmail.com> (vedaal@nym.hush.com's message of "Wed, 25 Jul 2012 12:14:26 -0400") References: <20120725161426.E2A796F448@smtp.hushmail.com> Message-ID: <87obn3dby4.fsf@vigenere.g10code.de> On Wed, 25 Jul 2012 18:14, vedaal at nym.hush.com said: > current windows does allow pipe, but not grep Actually since PCDOS 2.11 (~1984); although temporary files were used to implement them. IIRC, there is a grep like tool on Windows as well. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Jul 25 19:12:10 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 25 Jul 2012 13:12:10 -0400 Subject: GPG key to authenticate to SSH? In-Reply-To: <500FDD4F.9030503@websource.ch> References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> <500EFFCF.3070206@budts.be> <87txwwcfz4.fsf@vigenere.g10code.de> <500FDD4F.9030503@websource.ch> Message-ID: <501028EA.1040504@fifthhorseman.net> On 07/25/2012 07:49 AM, Marco Steinacher wrote: > I think 'monkeysphere subkey-to-ssh-agent' will do the same with GnuPG > versions before 2.1. See > http://lists.gnupg.org/pipermail/gnupg-users/2009-July/036946.html yes, this is correct. > It will extract the keygrip of your authentication subkey and add it to > sshcontrol. This isn't actually how "monkeysphere subkey-to-ssh-agent" (or, more concisely, "monkeysphere s") works; instead it actually extracts the authentication-capable subkey, reformats it in accordance with what ssh expects, and feeds it to ssh-agent using the standard ssh-add. reading sshcontrol's documentation in the texi doc, it occurs to me that this indication of which key should be used for ssh should in many use cases be visible to ssh servers as well. If for some reason the authentication-capable flag isn't sufficient to indicate this, perhaps some sort of OpenPGP notation in the binding signature would be useful? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Wed Jul 25 19:16:33 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 25 Jul 2012 19:16:33 +0200 Subject: old vs new gnupg - encrypting files In-Reply-To: References: <6933845.2Dk9xnJhG5@inno> Message-ID: <33590873.iA1Nnhnc7U@inno> Am Mi 25.07.2012, 12:48:57 schrieb Chris Clifton: > Forgive me, can you elaborate on 'encrypting the file to the other one and > your own key' ? You can give several recipients. The data is encrypted symmetrically (by AES e.g.) by a random key. This random key is asymmetrically encrypted to all recipients (or even to a passphrase). Thus an additional recipient increases the size of the resulting file slightly only. gpg --recipient 0x12345678 --recipient 0x87654321 --encrypt ./my/file See --encrypt-to. This way you can check whether you can decrypt the data yourself at least. Furthermore it would have been a lot more useful to get the full error message of your recipient instead of a simple "cannot". Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From juice.qr at gmail.com Wed Jul 25 18:48:57 2012 From: juice.qr at gmail.com (Chris Clifton) Date: Wed, 25 Jul 2012 12:48:57 -0400 Subject: old vs new gnupg - encrypting files In-Reply-To: <6933845.2Dk9xnJhG5@inno> References: <6933845.2Dk9xnJhG5@inno> Message-ID: Forgive me, can you elaborate on 'encrypting the file to the other one and your own key' ? Thanks, Chris On Wed, Jul 25, 2012 at 12:33 PM, Hauke Laging < mailinglisten at hauke-laging.de> wrote: > Am Mi 25.07.2012, 10:37:54 schrieb Chris Clifton: > > > I moved the gpg keyring to the new server and can encrypt files just fine > > with the keys on the public keyring, no problems. We have one public key > > however that the end user (that we send the encrypted files to) is saying > > they can't decrypt when we encrypt with their key on the new server. > > Have you tried encrypting the file to the other one and your own key > simultaneously? That might allow a better comparison of the difference > between > the two systems. > > Hauke > -- > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juice.qr at gmail.com Wed Jul 25 19:47:26 2012 From: juice.qr at gmail.com (Chris Clifton) Date: Wed, 25 Jul 2012 13:47:26 -0400 Subject: old vs new gnupg - encrypting files In-Reply-To: <33590873.iA1Nnhnc7U@inno> References: <6933845.2Dk9xnJhG5@inno> <33590873.iA1Nnhnc7U@inno> Message-ID: Got it, I will try that next. Thanks. On Wed, Jul 25, 2012 at 1:16 PM, Hauke Laging wrote: > Am Mi 25.07.2012, 12:48:57 schrieb Chris Clifton: > > Forgive me, can you elaborate on 'encrypting the file to the other one > and > > your own key' ? > > You can give several recipients. The data is encrypted symmetrically (by > AES > e.g.) by a random key. This random key is asymmetrically encrypted to all > recipients (or even to a passphrase). Thus an additional recipient > increases > the size of the resulting file slightly only. > > gpg --recipient 0x12345678 --recipient 0x87654321 --encrypt ./my/file > > See --encrypt-to. > > This way you can check whether you can decrypt the data yourself at least. > > Furthermore it would have been a lot more useful to get the full error > message > of your recipient instead of a simple "cannot". > > > Hauke > -- > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Wed Jul 25 20:44:16 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 25 Jul 2012 11:44:16 -0700 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> <500F4A78.4050301@gmail.com> <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> Message-ID: <50103E80.4040607@dougbarton.us> On 07/25/2012 05:29, antispam06 at sent.at wrote: > I keep the key on the same phisical drive as the encrypted document. > That's security through obscurity assuming the other one won't know > where to search for the key, which is not stored with the right > extension or in the most common place. I'm still not sure you grasp the security concepts involved here. Short version, everything that you're doing is useless against a determined attacker. Particularly, obscuring the location and extension of the key are incredibly naive, and indicate that you just don't understand what's going on. I'm sorry to be so blunt, but you keep perpetuating this discussion even though some really smart people have given you excellent advice. The way that you protect your secret key is to hide it behind strong encryption, with a strong passphrase. GnuPG takes care of the strong encryption by default, so the passphrase is entirely your responsibility. That said, given your particular use case, your best bet would be to forgo encrypting the file to any key at all. Use asymmetric encryption with a very strong randomly generated password, and store the password in your KeePass wallet. Good luck, Doug -- If you're never wrong, you're not trying hard enough From wk at gnupg.org Wed Jul 25 21:19:08 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Jul 2012 21:19:08 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <501028EA.1040504@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 25 Jul 2012 13:12:10 -0400") References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> <500EFFCF.3070206@budts.be> <87txwwcfz4.fsf@vigenere.g10code.de> <500FDD4F.9030503@websource.ch> <501028EA.1040504@fifthhorseman.net> Message-ID: <87k3xrd4yb.fsf@vigenere.g10code.de> On Wed, 25 Jul 2012 19:12, dkg at fifthhorseman.net said: > reading sshcontrol's documentation in the texi doc, it occurs to me that > this indication of which key should be used for ssh should in many use > cases be visible to ssh servers as well. If for some reason the > authentication-capable flag isn't sufficient to indicate this, perhaps The thing here is that gpg-agent is protocol agnostic. It does not know about OpenPGP or X.509. It merely manages the raw key material. There is no capability flag at all. Agreed, there should be one so that you won't accidentally use an encryption key for signing etc. However it can't be enforced and thus I neglected to implement it. So you may put any key from privates-keys-v1.d into sshcontrol and it will work as ssh key as long as some basic properties are okay. sshcontrol is used as a filter to present only those keys to ssh which are listed in it. With capability flags in private-keys-v1.d we could add a wildcard entry into sshcontrol and automagically use all keys flaged as "authenticate" or "use-for-ssh". However, I am not sure whether this is a good idea, given that ssh iterates over all available keys and thus it may take some time to setup a conenction in case you have too many ssh capable keys available in gpg-agent. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Wed Jul 25 21:42:04 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 25 Jul 2012 21:42:04 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <87k3xrd4yb.fsf@vigenere.g10code.de> References: <500C5A05.5050209@budts.be> <501028EA.1040504@fifthhorseman.net> <87k3xrd4yb.fsf@vigenere.g10code.de> Message-ID: <1988228.48VnfidpLI@inno> Am Mi 25.07.2012, 21:19:08 schrieb Werner Koch: > With capability flags in private-keys-v1.d we could add a wildcard entry > into sshcontrol and automagically use all keys flaged as "authenticate" > or "use-for-ssh". However, I am not sure whether this is a good idea, > given that ssh iterates over all available keys and thus it may take > some time to setup a conenction in case you have too many ssh capable > keys available in gpg-agent. Thus those few people who really have so many A-keys would simply not use this wildcard. Or they use both the wildcard and the current configuration so that they can tell gpg-agent which keys are the most often used so that these are tried first. Does gpg-agent currently care about the order of the entries? Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From juice.qr at gmail.com Wed Jul 25 23:17:15 2012 From: juice.qr at gmail.com (Chris Clifton) Date: Wed, 25 Jul 2012 17:17:15 -0400 Subject: old vs new gnupg - encrypting files In-Reply-To: <33590873.iA1Nnhnc7U@inno> References: <6933845.2Dk9xnJhG5@inno> <33590873.iA1Nnhnc7U@inno> Message-ID: Ok, I encrypted the file in question on the new server with : gpg -vvve -r xxx -r YYY -o filename.dat.pgp filename.dat Where xxx is the problematic key and YYY is our key, and I was able to decrypt the file using my private key with no problems. Not sure if that gives us any more info. I can decrypt with our key at least. Thanks, Chris On Wed, Jul 25, 2012 at 1:16 PM, Hauke Laging wrote: > Am Mi 25.07.2012, 12:48:57 schrieb Chris Clifton: > > Forgive me, can you elaborate on 'encrypting the file to the other one > and > > your own key' ? > > You can give several recipients. The data is encrypted symmetrically (by > AES > e.g.) by a random key. This random key is asymmetrically encrypted to all > recipients (or even to a passphrase). Thus an additional recipient > increases > the size of the resulting file slightly only. > > gpg --recipient 0x12345678 --recipient 0x87654321 --encrypt ./my/file > > See --encrypt-to. > > This way you can check whether you can decrypt the data yourself at least. > > Furthermore it would have been a lot more useful to get the full error > message > of your recipient instead of a simple "cannot". > > > Hauke > -- > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Thu Jul 26 00:48:06 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 26 Jul 2012 00:48:06 +0200 Subject: old vs new gnupg - encrypting files In-Reply-To: References: <33590873.iA1Nnhnc7U@inno> Message-ID: <12111368.2Yfp5y7a8Z@inno> Am Mi 25.07.2012, 17:17:15 schrieb Chris Clifton: > Where xxx is the problematic key and YYY is our key, and I was able to > decrypt the file using my private key with no problems. Do the same on the other system and have a look at the resulting encrypted files via gpg -v --list-packets filename.dat.pgp and check for differences in the outputs. I don't have a real idea yet what could be the problem but perhaps we are lucky with this general checking. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From expires2012 at rocketmail.com Thu Jul 26 02:02:07 2012 From: expires2012 at rocketmail.com (MFPA) Date: Thu, 26 Jul 2012 01:02:07 +0100 Subject: Is there a GnuPG command that shows the number of keys on a keyring? In-Reply-To: <87hasxe97f.fsf@vigenere.g10code.de> References: <19910348005.20120724093327@my_localhost> <500E5F28.4010802@sixdemonbag.org> <87hasxe97f.fsf@vigenere.g10code.de> Message-ID: <1833472801.20120726010207@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 24 July 2012 at 11:37:24 AM, in , Werner Koch wrote: > In case you want to put this into a HOWTO, you better > write: > gpg2 --with-colons --list-keys|grep "^pub:"|wc -l > As usual this also works with gpg. And your comment in a post on another thread, saying there's a grep-like tool on Windows, prompted me to do a little research in that direction. It seems (at least on Windows XP) a broadly equivalent command is:- gpg --with-colons --list-keys|find /c "pub:" I could not find a way to check the string "pub:" was at the start of the line, so the figure will be inaccurate as a key count in the event any user-ids contain that string. Thanks to everybody who helped me with this question. - -- Best regards MFPA mailto:expires2012 at rocketmail.com Never lean forward to push an invisible object. -----BEGIN PGP SIGNATURE----- iQCVAwUBUBCJBaipC46tDG5pAQrZoAQAighoUwaB6m+t/9AOMSgZrUT55UUMHIN6 9pVqIMm1jJIcJJWYhhxBhpAfIaxLFT8l7Tw95NHIsxk+WE4+zgvn3npEActrsLc9 zarOQsIIwporySibafiNTex2amwjIGbGX1MjcXa9/qSlLleHUQJUHrhpGNFX30rs UQZOPju2Aeg= =CKCE -----END PGP SIGNATURE----- From faramir.cl at gmail.com Thu Jul 26 02:40:28 2012 From: faramir.cl at gmail.com (Faramir) Date: Wed, 25 Jul 2012 20:40:28 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500F804D.7070107@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <500F5830.4080808@gmail.com> <500F804D.7070107@sixdemonbag.org> Message-ID: <501091FC.9030207@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 25-07-2012 1:12, Robert J. Hansen escribi?: > On 7/24/2012 10:21 PM, Faramir wrote: >> Clearly I'm out of my league there. I had heard about that, but >> later I also heard about stacking different algos (with different >> keys of course) to increase security. > > I'm unaware of any reputable reference that recommends this > practice. That's not to say no such reference exists, only that if > one exists I'm unaware of it. If I even saw a reputable reference, I forgot it. I know TrueCrypt can stack up to 3 different encryption algorithms, but that is not the same as if Schneier, Shamir or that kind of professionals say it is a good measure. I know Schneier adviced to be careful, because you don't know if you will improve security or decrease it, but that was a long time ago, maybe now they know a bit more, but if they do, I could not find a reference. Now I found this article, with some references to papers: http://blog.cryptographyengineering.com/2012/02/multiple-encryption.html >> Anyway, do you know about any list of "compatible" encryption >> algorithms? I mean, pairs that work well together. > > The better question, to me at least, is "why would I want to do > this?" Probably because some software offers the option to do it, it would be good to know what to avoid, other than "avoid everything". > Cryptosystems tend to fail predominantly due to human error, then > to software bugs. Consider that since PGP 2.6 was released in ... > what was it, '91? ... not one single encryption algorithm used by > PGP has ever been broken. Although IDEA is not well-regarded by > modern standards it's still a safe cipher; and RSA is still, well, > RSA. In that case, it might make a sense to, lets say, compress and encrypt a file using winzip, and then compress and encrypt it using 7zip, in case one implementation fails, the other might hold. Or in the case of the original question, storing the private keyring inside a keepass database. If there is a bug in GnuPG, maybe keepass will hold. If there is not a bug in gpg, then it doesn't matter if keepass is bug-free or not. It might make a sense using cascade encryption in truecrypt, just in case there is a bug in the implementation of one of the encryption algorithms. But if the bug is elsewhere, since it is the same program, the bug would affect both ciphers, and there is no gain in using cascade. > If the algorithms are unlikely to be broken but the likelihood of > security-impacting software bugs is essentially certain, then > stacking algorithms would seem to be ill-advised. Stacking > algorithms increases the complexity of the code, increases the > number of keys which must be True. If we combine 2 different systems (lets say, winrar and keepass) would avoid the danger of more bugs, but of course, won't help with the increase of keys. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQEJH8AAoJEMV4f6PvczxA+C0H/iCHeAdwUTdyUAFFbyHBl0vU M6eiG3S7vM+QoU5YKFol16IqVBH0rdZpUNFVe0IgWLLX0CPsyaLuMCit2QWUZlYT eXRV86O2gwPg+qlbd9JNB1gW25otjwJDbCOQckvhz05N/MELSQ0ft7OydiIs45FO 8EM6oxIahiqky8tb3EFm6b0o/JMxkz6rzmi5vojwoDi7PF1p32JO+L6oYw+0nzha zqlEkg3/ZlRIUGgMdNj/4+ibAw3N4ze6S2pUuw7+yKaXBYAl0yqxv2m/T2PKAV1y NxqZJHju6154JAxdT4V+pDhGKWIu+a4hwsGye9McBK9m1B4BvkOvkMgdB92keJk= =fAFT -----END PGP SIGNATURE----- From faramir.cl at gmail.com Thu Jul 26 02:54:05 2012 From: faramir.cl at gmail.com (Faramir) Date: Wed, 25 Jul 2012 20:54:05 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <20120725065027.GA2625@fritha.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <500F5830.4080808@gmail.com> <20120725065027.GA2625@fritha.org> Message-ID: <5010952D.4000909@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 25-07-2012 2:50, Heinz Diehl escribi?: > On 25.07.2012, Faramir wrote: > >> Clearly I'm out of my league there. I had heard about that, but >> later I also heard about stacking different algos (with different >> keys of course) to increase security. > > What's the model of threat in your case, actually? Usually, the > crypto algorithm isn't the weakest part in the whole scenario, and > stacking different algorithms will therefore not make any sense at > all. I'm just talking (and thinking) about the question from the thread starter, so this discussion doesn't apply directly to my threat model. I find the question interesting, because maybe, some day, I might think about storing one encrypted thing inside another encrypted thing. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQEJUtAAoJEMV4f6PvczxAy20IAKx2qDgEb/BKMJLwXLgRUKsE 0+KaJ4GMhl08jsBUxKYNf6E+oX35Kq1HY087RAJQh0c+W3KwQRFYfIQHRCa+SlkU UwpXjI80gCV9qVwbIqBllSYpfX0Dsu17gUTW5Rn8sH2PAF9JkMTJ2oaphOUKGtqL do1YnHie0bZWdHyudkmGfNnDIvjpqxNLJy56df6B/Pn/JL5yLtz0y2vWV9k/TETV Z5rOY/gtKHn6We4tR9r8F4ypK9vyk1W5iB4zVcgboYygYMFqJ8qMN+vi1fp/Pkyh Gpocl/dchoxCFCSjBAEehjKLEODSnh/DLQ8HQ8KBHEuXTw9mOTPx/wEmCQenQaY= =0MBk -----END PGP SIGNATURE----- From dougb at dougbarton.us Thu Jul 26 02:58:00 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 25 Jul 2012 17:58:00 -0700 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <5010952D.4000909@gmail.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <500F5830.4080808@gmail.com> <20120725065027.GA2625@fritha.org> <5010952D.4000909@gmail.com> Message-ID: <50109618.7050102@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/25/2012 17:54, Faramir wrote: > I find the question interesting, because maybe, some day, I might > think about storing one encrypted thing inside another encrypted > thing. There's no *harm* in doing that (absent potential outliers), and there are valid use cases for doing it. It's just important to understand that by doing so you are not necessarily increasing security for the (multiply) encrypted thing. Doug - -- If you're never wrong, you're not trying hard enough -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJQEJYYAAoJEFzGhvEaGryEvX4H/1f06jz1iKB+9cl+dzMfkuy9 /mkzAXDPIbBKtaFWmOVOVewb/8028woRKFJrMMUkTLuCJOYNl1PX8qP0sQWE1dNG xz0OhyQq8v8L48SyFWmX5hqaPypnLboohJEOHqStrTW8MbJPLIeizY2xdp5Qt38t vIoQ4Ta1XCljvYiSG81ND7LroUVuN9EL8ysyr0sa6CtpjOJEUMbKDoL8z3x6sNBk I9NpiEpuOekEIvNggJ+haqUocfpyQ3XvdmHl4iiWNQJxkhtSLIoc5eKEfOUTp+qe dp5rtriM64Unzr9wC8qaqtLD/fJn7WlcisCN2ACISj4MMRb0VYHTJmxq9Ku17U4= =fpLD -----END PGP SIGNATURE----- From faramir.cl at gmail.com Thu Jul 26 03:30:42 2012 From: faramir.cl at gmail.com (Faramir) Date: Wed, 25 Jul 2012 21:30:42 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> <500F4A78.4050301@gmail.com> <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> Message-ID: <50109DC2.9040709@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 25-07-2012 8:29, antispam06 at sent.at escribi?: > > On Wed, Jul 25, 2012, at 03:23, Faramir wrote: ... >>> Yes, security through obscurity. A possible attacker won't know >>> for ... >> I don't know why do you say security through obscurity. Private >> keys can be stored encrypted, so even if somebody steal them, the >> thieve ... > I keep the key on the same phisical drive as the encrypted > document. That's security through obscurity assuming the other one > won't know where to search for the key, which is not stored with > the right extension or in the most common place. Not right, if your secret key is protected by a passphrase (or strong password), it doesn't matter if the attacker know where to find it. Actually, the attacked is very likely to know where it is, since probably it will be at the default folder. But finding it doesn't mean he can USE it, without the passphrase, it is just a "soup of bits". >> A hacker will know what key he needs to open a file, because the >> encrypted file say it, unless the sender selects hide recipient's >> key ... > So he or she will have to locate the right key. Reasonable would be > to keep the key away, at least on some removable media. Most of us want to keep our keys away from other people, and also keep them protected by a passphrase, in case the key falls in the wrong hands. The attacker needs 2 things: the key and the passphrase. It is a matter of making things harder for the attacker. >>> It employs far less characters. Yet it can be looong. How >>> about that? Is that any better? 45 ASCII lowercase with a >>> uppercase ASCII and a couple of signs is better than 16 random >>> alphanumerics and signs? >> >> I bet it is, as long as that 45 characters passphrase is not >> something that could be found on dictionaries, or combining >> dictionary words. But probably it is an overkill. Anyway, Keepass >> has a built in ... > If only dictionary attacks would be the the problem than any > longish verse from a popular band could do it. Just add a comma in > some weird place and you have broken even the lyrics hacker. Don't forget there can be attacks with dictionary and mutators. Of course, you can increase mutators until the attack becomes infeasible too (what is the point when a dictionary attack with mutators become a bruteforce attack?). Anyway, a good password should include uppercase and lowercase, numbers and special characters. One of each of these forces the attacker to increase the key space (even 1 special character forces the attacker to include them in the attack). Of course, there may be a sub-set of special characters known as "most used special characters". And of course, make it long enough a bruteforce attack is infeasible for your adversary. And what is infeasible for your adversary? Depends on your threat model. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQEJ3CAAoJEMV4f6PvczxAOLsH/24OaRbK88Z9GHtrFRItn/4F oRvZrmc7ldffOPjuduUdpuOY6QhYzfPew1c0o3+OsW5HlxkRtk9LdihcDLGRnUd7 bA5/VFy6fTxKxnW22GYwy2Ht2NNO+s/KVe9ZRK/LMCWHhvTAT/z1DVvu3i3sQadL DMMqOKdlouuuyKk0C8MCJX6siVx5HBCn/c8Eu/a+gWZSayQBIjnlJamD7fjhAuzh ze5VytLaNLrf2FXO9oJZ/1WPCSa2ICaTPqbtsli+Z4Q1UifwjqYYlY0+7h+T6LBa CAFtPh+kNsa0lqefusR/n9ytWeU3k7LiTCJnGGHqk3VykdyNkD1+eS8PWi6uG/k= =vAef -----END PGP SIGNATURE----- From ben at adversary.org Thu Jul 26 05:50:25 2012 From: ben at adversary.org (Ben McGinnes) Date: Thu, 26 Jul 2012 13:50:25 +1000 Subject: GPG 2.1 beta compilation error Message-ID: <5010BE81.2010601@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I've just tried compiling GPG 2.1.0 beta 3 on a CentOS/RHEL 5 box. I'm installing in and to /usr/local with all the dependencies in the same location. I configured it with the following options: ./configure --enable-symcryptrun --enable-gpgtar --enable-selinux-support The configuration process was fine, but when I tried to make it I received this error: passphrase.c: In function ?passphrase_to_dek_ext?: passphrase.c:584: warning: implicit declaration of function ?gcry_kdf_derive? passphrase.c:585: error: ?GCRY_KDF_ITERSALTED_S2K? undeclared (first use in this function) passphrase.c:585: error: (Each undeclared identifier is reported only once passphrase.c:585: error: for each function it appears in.) passphrase.c:586: error: ?GCRY_KDF_SALTED_S2K? undeclared (first use in this function) passphrase.c:587: error: ?GCRY_KDF_SIMPLE_S2K? undeclared (first use in this function) make[2]: *** [passphrase.o] Error 1 make[2]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3/g10' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3' make: *** [all] Error 2 Is this a bug or do I need to fix something? Regards, Ben -----BEGIN PGP SIGNATURE----- iEYEAREKAAYFAlAQvoEACgkQNxrFv6BK4xMAmwCgij5wCTBXkJpQ71uEpVF1Y86b mU8AoJ+AYZsJ5Z6oD5N+tcmCsf+xxTV1 =jAZe -----END PGP SIGNATURE----- From ben at adversary.org Thu Jul 26 06:10:57 2012 From: ben at adversary.org (Ben McGinnes) Date: Thu, 26 Jul 2012 14:10:57 +1000 Subject: GPG 2.1 beta compilation error In-Reply-To: <5010BE81.2010601@adversary.org> References: <5010BE81.2010601@adversary.org> Message-ID: <5010C351.5060404@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/07/12 1:50 PM, Ben McGinnes wrote: > Hello, I've just tried compiling GPG 2.1.0 beta 3 on a CentOS/RHEL > 5 box. I'm installing in and to /usr/local with all the > dependencies in the same location. > > I configured it with the following options: > > ./configure --enable-symcryptrun --enable-gpgtar > --enable-selinux-support > > The configuration process was fine, but when I tried to make it I > received this error: > > passphrase.c: In function ?passphrase_to_dek_ext?: > passphrase.c:584: warning: implicit declaration of function > ?gcry_kdf_derive? passphrase.c:585: error: > ?GCRY_KDF_ITERSALTED_S2K? undeclared (first use in this function) > passphrase.c:585: error: (Each undeclared identifier is reported > only once passphrase.c:585: error: for each function it appears > in.) passphrase.c:586: error: ?GCRY_KDF_SALTED_S2K? undeclared > (first use in this function) passphrase.c:587: error: > ?GCRY_KDF_SIMPLE_S2K? undeclared (first use in this function) > make[2]: *** [passphrase.o] Error 1 make[2]: Leaving directory > `/usr/local/src/gnupg-2.1.0beta3/g10' make[1]: *** [all-recursive] > Error 1 make[1]: Leaving directory > `/usr/local/src/gnupg-2.1.0beta3' make: *** [all] Error 2 > > Is this a bug or do I need to fix something? I just tried it without passing any options to configure and received this error when running make: tatus.c:25:26: error: status-codes.h: No such file or directory status.c: In function ?get_status_string?: status.c:32: warning: implicit declaration of function ?statusstr_msgidxof? status.c:36: error: ?statusstr_msgstr? undeclared (first use in this function) status.c:36: error: (Each undeclared identifier is reported only once status.c:36: error: for each function it appears in.) status.c:36: error: ?statusstr_msgidx? undeclared (first use in this function) make[3]: *** [libcommon_a-status.o] Error 1 make[3]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3' make: *** [all] Error 2 Regards, Ben -----BEGIN PGP SIGNATURE----- iEYEAREKAAYFAlAQw1EACgkQNxrFv6BK4xP31ACg9lbUi1cwmY0K/38K0F5aQNAX 9L0AoJgqWpMnGTwops/uAj3fR3SQKdNT =xAXU -----END PGP SIGNATURE----- From wk at gnupg.org Thu Jul 26 09:20:36 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Jul 2012 09:20:36 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <1988228.48VnfidpLI@inno> (Hauke Laging's message of "Wed, 25 Jul 2012 21:42:04 +0200") References: <500C5A05.5050209@budts.be> <501028EA.1040504@fifthhorseman.net> <87k3xrd4yb.fsf@vigenere.g10code.de> <1988228.48VnfidpLI@inno> Message-ID: <87ehnzc7jv.fsf@vigenere.g10code.de> On Wed, 25 Jul 2012 21:42, mailinglisten at hauke-laging.de said: > tried first. Does gpg-agent currently care about the order of the entries? No, it does a plain readdir and only then checks whether the key is in sshcontrol: /* Fixme: We should better iterate over the control file and check whether the key file is there. This is better in respect to performance if there are a lot of keys in our key storage. */ Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 26 09:25:05 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Jul 2012 09:25:05 +0200 Subject: GPG 2.1 beta compilation error In-Reply-To: <5010BE81.2010601@adversary.org> (Ben McGinnes's message of "Thu, 26 Jul 2012 13:50:25 +1000") References: <5010BE81.2010601@adversary.org> Message-ID: <87a9ync7ce.fsf@vigenere.g10code.de> On Thu, 26 Jul 2012 05:50, ben at adversary.org said: > passphrase.c:585: error: ?GCRY_KDF_ITERSALTED_S2K? undeclared (first > use in this function) You need at least Libgcrypt 1.5.0. However, configure should have detected this. Thus the build process accidentally picked up another gcrypt.h than the configure test. Check the config.log and an actual cc invocation line to figure out what went wrong. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ben at adversary.org Thu Jul 26 09:54:29 2012 From: ben at adversary.org (Ben McGinnes) Date: Thu, 26 Jul 2012 17:54:29 +1000 Subject: GPG 2.1 beta compilation error In-Reply-To: <87a9ync7ce.fsf@vigenere.g10code.de> References: <5010BE81.2010601@adversary.org> <87a9ync7ce.fsf@vigenere.g10code.de> Message-ID: <5010F7B5.9030106@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/07/12 5:25 PM, Werner Koch wrote: > On Thu, 26 Jul 2012 05:50, ben at adversary.org said: > >> passphrase.c:585: error: ?GCRY_KDF_ITERSALTED_S2K? undeclared >> (first use in this function) > > You need at least Libgcrypt 1.5.0. However, configure should have > detected this. Thus the build process accidentally picked up > another gcrypt.h than the configure test. Check the config.log > and an actual cc invocation line to figure out what went wrong. I compiled libgcrypt-1.5.0-beta1 in /usr/local, but there's probably another version elsewhere. Should I be using the following flags? --with-libgpg-error-prefix=PFX --with-libgcrypt-prefix=PFX --with-libassuan-prefix=PFX --with-ksba-prefix=PFX --with-pth-prefix=PFX Any or all of them? Should I just use "/usr/local" with them or full paths to binaries? Regards, Ben -----BEGIN PGP SIGNATURE----- iEYEAREKAAYFAlAQ97UACgkQNxrFv6BK4xOtJQCZAaAUWECljnBiDF8SVuoXg09N 6LMAn1x8uFO/m9SR/Owe4fygZKUfVU6N =pS5T -----END PGP SIGNATURE----- From ben at adversary.org Thu Jul 26 10:05:43 2012 From: ben at adversary.org (Ben McGinnes) Date: Thu, 26 Jul 2012 18:05:43 +1000 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <500C681C.2020201@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> Message-ID: <5010FA57.90909@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 23/07/12 6:52 AM, Robert J. Hansen wrote: > > Cryptography is a subtle art, and algorithms interact with each > other in deeply surprising and counterintuitive ways. Before > advocating that algorithms be composed together to achieve certain > results, it's good to make sure that these compositions are > cryptanalytically sound. :) On a semi-related tangent, does this mean that utilising the three symmetric ciphers available in TrueCrypt (AES, Serpent and Twofish) is a bad idea or do they play well together? Also, if you had to pick one of those three, which would you choose (for general purposes rather than a specific threat model and ignoring the possible speed differences between AES and Serpent)? Regards, Ben -----BEGIN PGP SIGNATURE----- iEYEAREKAAYFAlAQ+lcACgkQNxrFv6BK4xOxzQCgkYK0ZTjlZbOThwUaUMgkaro2 X3gAniwBUuNN9K6fquq9XvgYywB6eOdJ =cIvN -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Jul 26 10:40:56 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 26 Jul 2012 04:40:56 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <5010FA57.90909@adversary.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <5010FA57.90909@adversary.org> Message-ID: <50110298.3010303@sixdemonbag.org> On 7/26/2012 4:05 AM, Ben McGinnes wrote: > On a semi-related tangent, does this mean that utilising the three > symmetric ciphers available in TrueCrypt (AES, Serpent and Twofish) > is a bad idea or do they play well together? My understanding is they at least tolerate each other, but I'm unaware of any serious analysis that suggests you enjoy increased cryptographic strength by stacking them. It wouldn't surprise me if you did, but at the same time ... as I mentioned earlier, I really don't see the point. > Also, if you had to pick one of those three, which would you choose > (for general purposes rather than a specific threat model and > ignoring the possible speed differences between AES and Serpent)? This presumes I'm competent to have an opinion. I really don't think I am. Evaluating cryptographic algorithms is almost as hard as designing them. It's the sort of thing that's best done by a handful of experts all looking at the algorithms through slightly different prisms of experience and skill. For instance, I don't like Serpent very much on account of how complex it is. My rule of thumb is, "if I don't believe an undergraduate in computer science can understand this algorithm, how can I expect people to implement this algorithm correctly?" So, had I been on the AES selection committee, I'd have given Serpent a thumbs-down. Other people with different perspectives would've given it thumbs-ups and thumbs-down, and our ultimate recommendation would take into account all the input of the different experts on the selection committee. But whenever you ask one person for his or her opinion on a cipher, all you're getting is one perspective, and you really need more perspectives than that. Still, you asked a question, and now that I've spent three paragraphs explaining why you shouldn't trust my answer I'll give you my answer: Twofish. Most symmetric ciphers nowadays are built around Feistel networks. We have a lot of experience with Feistel networks: many algorithms built around them have held up quite well over the years. (3DES, for instance, which pretty much every cryppie holds in a mixture of distaste, disgust, fear, terror, awe and reverence, is built around a Feistel network. 30+ years, no really meaningful results against it.) Feistel networks make me happy: who doesn't like a track record of success? Rijndael is not a Feistel cipher. That doesn't mean it's bad, far from it. But if Feistel networks give me the warm fuzzies, then that means I need to strike non-Feistel networks from my list. I don't like Serpent's complexity: I think that leads to difficulty in implementing it. By comparison, I've implemented Twofish a couple of times and have seen undergraduates implement it correctly. So, yeah, for my money I prefer Twofish. But I don't think you should trust my opinion worth a damn. :) From ben at adversary.org Thu Jul 26 11:56:09 2012 From: ben at adversary.org (Ben McGinnes) Date: Thu, 26 Jul 2012 19:56:09 +1000 Subject: AES vs. Serpent vs. Twofish (was Re: KeePass or any other password wallet to store and transport keys) In-Reply-To: <50110298.3010303@sixdemonbag.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <5010FA57.90909@adversary.org> <50110298.3010303@sixdemonbag.org> Message-ID: <50111439.10309@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/07/12 6:40 PM, Robert J. Hansen wrote: > On 7/26/2012 4:05 AM, Ben McGinnes wrote: >> On a semi-related tangent, does this mean that utilising the >> three symmetric ciphers available in TrueCrypt (AES, Serpent and >> Twofish) is a bad idea or do they play well together? > > My understanding is they at least tolerate each other, but I'm > unaware of any serious analysis that suggests you enjoy increased > cryptographic strength by stacking them. It wouldn't surprise me > if you did, but at the same time ... as I mentioned earlier, I > really don't see the point. Okay. >> Also, if you had to pick one of those three, which would you >> choose (for general purposes rather than a specific threat model >> and ignoring the possible speed differences between AES and >> Serpent)? > > This presumes I'm competent to have an opinion. I really don't > think I am. Evaluating cryptographic algorithms is almost as hard > as designing them. It's the sort of thing that's best done by a > handful of experts all looking at the algorithms through slightly > different prisms of experience and skill. Fair enough. Unfortunately I don't have any cryptographers or cryptanalysts on speed dial. This group is probably one amongst my better sources of information. Although maybe I should be asking Werner since he's clearly implemented all three algorithms (and several others). > For instance, I don't like Serpent very much on account of how > complex it is. My rule of thumb is, "if I don't believe an > undergraduate in computer science can understand this algorithm, > how can I expect people to implement this algorithm correctly?" > So, had I been on the AES selection committee, I'd have given > Serpent a thumbs-down. Other people with different perspectives > would've given it thumbs-ups and thumbs-down, and our ultimate > recommendation would take into account all the input of the > different experts on the selection committee. Interesting. Most of the things I've read on Serpent, which admittedly isn't much, is about how it was not accepted for AES because of the speed aspects rather than other aspects and that it may be more secure. > But whenever you ask one person for his or her opinion on a > cipher, all you're getting is one perspective, and you really need > more perspectives than that. Exactly. I figured this would be a good place to start and I'd definitely like to read what other list members think on this topic. > Still, you asked a question, and now that I've spent three > paragraphs explaining why you shouldn't trust my answer I'll give > you my answer: Twofish. Heh. Caveats are important, especially on a topic like this which so often looks like black magic. > Most symmetric ciphers nowadays are built around Feistel networks. > We have a lot of experience with Feistel networks: many algorithms > built around them have held up quite well over the years. (3DES, > for instance, which pretty much every cryppie holds in a mixture > of distaste, disgust, fear, terror, awe and reverence, is built > around a Feistel network. 30+ years, no really meaningful results > against it.) Feistel networks make me happy: who doesn't like a > track record of success? This is a very good point and you're also right about the 3DES thing. > Rijndael is not a Feistel cipher. That doesn't mean it's bad, far > from it. Cool. > But if Feistel networks give me the warm fuzzies, then that means > I need to strike non-Feistel networks from my list. Okay, this bit I don't follow. I get favouring Feistel networks because of their proven track record, but I don't see why it would necessitate ruling out Substitution-Permutation networks and other types of ciphers. > I don't like Serpent's complexity: I think that leads to > difficulty in implementing it. By comparison, I've implemented > Twofish a couple of times and have seen undergraduates implement it > correctly. Okay, that makes sense. > So, yeah, for my money I prefer Twofish. But I don't think you > should trust my opinion worth a damn. :) Fair enough. I think I'd like to get more opinions now. Regards, Ben -----BEGIN PGP SIGNATURE----- iEYEAREKAAYFAlARFDkACgkQNxrFv6BK4xM4XACgjL8ESxQj/rH68W1H9Y8cYuUj ozYAnRWLAceszUxCnyyyVNnuEPb12+KC =P9Zt -----END PGP SIGNATURE----- From ben at adversary.org Thu Jul 26 12:40:15 2012 From: ben at adversary.org (Ben McGinnes) Date: Thu, 26 Jul 2012 20:40:15 +1000 Subject: GPG 2.1 beta compilation error In-Reply-To: <87a9ync7ce.fsf@vigenere.g10code.de> References: <5010BE81.2010601@adversary.org> <87a9ync7ce.fsf@vigenere.g10code.de> Message-ID: <50111E8F.40302@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 26/07/12 5:25 PM, Werner Koch wrote: > On Thu, 26 Jul 2012 05:50, ben at adversary.org said: > >> passphrase.c:585: error: ?GCRY_KDF_ITERSALTED_S2K? undeclared >> (first use in this function) > > You need at least Libgcrypt 1.5.0. However, configure should have > detected this. Thus the build process accidentally picked up > another gcrypt.h than the configure test. Check the config.log and > an actual cc invocation line to figure out what went wrong. Okay, I tried it again with all the paths set to /usr/local and the following appeared in the configure log: configure: checking for libraries checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.10... yes (1.10) checking for libgcrypt-config... /usr/local/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.5.0... yes (1.5.0-beta1) checking LIBGCRYPT API version... okay checking for libassuan-config... /usr/local/bin/libassuan-config checking for LIBASSUAN - version >= 2.0.3... yes (2.0.3) checking LIBASSUAN API version... okay checking for ksba-config... /usr/local/bin/ksba-config checking for KSBA - version >= 1.2.0... yes (1.2.0) checking KSBA API version... okay checking for usb_bulk_write in -lusb... yes checking for usb_create_match... no checking for library containing dlopen... -ldl checking for encfs... /usr/bin/encfs checking for fusermount... /bin/fusermount checking for openpty in -lutil... yes checking for shred... /usr/bin/shred checking for pth-config... /usr/local/bin/pth-config checking for PTH - version >= 1.3.7... yes checking whether PTH installation is sane... yes You'd think that everything would be fine, but I still ended up with this: status.c:25:26: error: status-codes.h: No such file or directory status.c: In function ?get_status_string?: status.c:32: warning: implicit declaration of function ?statusstr_msgidxof? status.c:36: error: ?statusstr_msgstr? undeclared (first use in this function) status.c:36: error: (Each undeclared identifier is reported only once status.c:36: error: for each function it appears in.) status.c:36: error: ?statusstr_msgidx? undeclared (first use in this function) make[3]: *** [libcommon_a-status.o] Error 1 make[3]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnupg-2.1.0beta3' make: *** [all] Error 2 I've got the entire output of configure and make (up until the moment it hit that error), but it's about 25Kb of text and I'm unsure about sending the whole lot through to the list. I can send you the lot directly if you like. Regards, Ben -----BEGIN PGP SIGNATURE----- iEYEAREKAAYFAlARHo8ACgkQNxrFv6BK4xPemACZAeKtvn5WON/zse1RaTUEyz5R K+QAniOOnMWtngPfCOEiz+JO3Jy0smbz =IzNH -----END PGP SIGNATURE----- From htd at fritha.org Thu Jul 26 14:37:34 2012 From: htd at fritha.org (Heinz Diehl) Date: Thu, 26 Jul 2012 14:37:34 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <5010FA57.90909@adversary.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <5010FA57.90909@adversary.org> Message-ID: <20120726123734.GA1524@fritha.org> On 26.07.2012, Ben McGinnes wrote: > Also, if you had to pick one of those three, which would you choose > (for general purposes rather than a specific threat model and ignoring > the possible speed differences between AES and Serpent)? As far as I know, none of those three is broken. So if neither your security concept nor the algorithms speed matters: using Occam's razor, I would suggest "use the one which is preinstalled/predefined in your distribution". If it's none of those three, "use the one which is easiest to set up / to use for you". From htd at fritha.org Thu Jul 26 14:43:40 2012 From: htd at fritha.org (Heinz Diehl) Date: Thu, 26 Jul 2012 14:43:40 +0200 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <50109DC2.9040709@gmail.com> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> <500F4A78.4050301@gmail.com> <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> <50109DC2.9040709@gmail.com> Message-ID: <20120726124340.GB1524@fritha.org> On 26.07.2012, Faramir wrote: > > That's security through obscurity assuming the other one > > won't know where to search for the key, which is not stored with > > the right extension or in the most common place. > Not right, if your secret key is protected by a passphrase (or > strong password), it doesn't matter if the attacker know where to find > it. It does matter. Because the software which has generated the key can be flawed, and thus can have generated a flawed key. Nobody has to know about such flaws, it's quite likely that an attacker chooses not to publicate information about that, with the effect that he/she can use the security hole longer (maybe forever). If it's reported, it will be fixed immediately. > Actually, the attacked is very likely to know where it is, since > probably it will be at the default folder. This is why smartcards exist. From rjh at sixdemonbag.org Thu Jul 26 15:04:13 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 26 Jul 2012 09:04:13 -0400 Subject: AES vs. Serpent vs. Twofish (was Re: KeePass or any other password wallet to store and transport keys) In-Reply-To: <50111439.10309@adversary.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <5010FA57.90909@adversary.org> <50110298.3010303@sixdemonbag.org> <50111439.10309@adversary.org> Message-ID: <5011404D.1000803@sixdemonbag.org> On 7/26/2012 5:56 AM, Ben McGinnes wrote: > Interesting. Most of the things I've read on Serpent, which > admittedly isn't much, is about how it was not accepted for AES > because of the speed aspects rather than other aspects and that it > may be more secure. Yeah, well -- this tends to get written by people who have a thing for Serpent. :) The Serpent submission claimed that they tried to account for as-yet undiscovered cryptanalysis by having a sort of "safety net" against future discoveries. The problem is that if you believe Serpent on this, then you also probably need to believe Twofish and MARS when they make similar claims. My understanding is the AES voting went down like this: those who preferred speed over larger security margins tended to go for Rijndael, those who preferred larger security margins over speed tended to go for Serpent, and pretty much everyone agreed that Twofish was an excellent second choice. Under some kinds of voting (approval, instant runoff, etc.), Twofish would have won the AES competition as being the option highly preferable to the most people. Under the rules that were in play, the first-place finish went to Rijndael. >> But if Feistel networks give me the warm fuzzies, then that means I >> need to strike non-Feistel networks from my list. > > Okay, this bit I don't follow. I get favouring Feistel networks > because of their proven track record, but I don't see why it would > necessitate ruling out Substitution-Permutation networks and other > types of ciphers. It doesn't. We're not talking about which algorithms are good: we're talking about which algorithms I like. :) I like Feistel networks, and for that reason I tend to go for the Feistel cipher of the three. The fact Twofish is also simpler implementation-wise is icing on the cake. (Note that these lines are all somewhat arbitrary. A Feistel network that uses S-boxes is going to be very similar to a substitution-permutation network, and vice-versa. But still, Twofish is pretty clearly Feistel, and AES and Serpent are pretty clearly not.) From Lists.gnupg at mephisto.fastmail.net Thu Jul 26 21:34:45 2012 From: Lists.gnupg at mephisto.fastmail.net (Kevin Kammer) Date: Thu, 26 Jul 2012 15:34:45 -0400 Subject: Mac OS X 10.8 and OpenPGP Cards Message-ID: <20120726193445.GA1612@clarus.mgh.harvard.edu> Well, the inevitable has happened, again. I just upgraded from Mac OS X 10.7 to 10.8, and my ZeitControl cards, which were formerly working perfectly, are now inaccessible. ~ $ gpg2 --card-status gpg: selecting openpgp failed: Card error gpg: OpenPGP card not available: Card error Since I haven't had a lot more luck with using them on Fedora 17 either, which is what I'm running at home, it looks like I'm in a bit of a bind. This is what I get for being an "early adopter." From nicholas.cole at gmail.com Fri Jul 27 10:26:14 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 27 Jul 2012 09:26:14 +0100 Subject: Mac OS X 10.8 and OpenPGP Cards In-Reply-To: <20120726193445.GA1612@clarus.mgh.harvard.edu> References: <20120726193445.GA1612@clarus.mgh.harvard.edu> Message-ID: On Thu, Jul 26, 2012 at 8:34 PM, Kevin Kammer wrote: > Well, the inevitable has happened, again. > > I just upgraded from Mac OS X 10.7 to 10.8, and my ZeitControl cards, > which were formerly working perfectly, are now inaccessible. > > ~ $ gpg2 --card-status > gpg: selecting openpgp failed: Card error > gpg: OpenPGP card not available: Card error > > Since I haven't had a lot more luck with using them on Fedora 17 either, > which is what I'm running at home, it looks like I'm in a bit of a bind. > > This is what I get for being an "early adopter." If it is any consolation, it is working for me (Gemplus GemPC Reader) Have you installed the smartcard libraries? Best wishes, N. From sveniu at ifi.uio.no Fri Jul 27 13:46:02 2012 From: sveniu at ifi.uio.no (Sven Ulland) Date: Fri, 27 Jul 2012 13:46:02 +0200 Subject: [OT] Multi-user hierarchical password management via pki Message-ID: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> Is there such a thing as a multi-user, hierarchical, arbiter-less, pki-based password manager? I'm thinking specifically for use in a system administration context where you have multiple sub groups and cross-group roles that have access to different sets of passwords. * Users share one database, and can only view passwords that they are authorized to access. Authorization is either per-user or per-group. * Users and groups can be defined either statically, or perhaps dynamically looked up through external means like ldap, pam, etc. * Passwords are organized in a tree/folder structure, and each node (including leaves, i.e. passwords) is associated with one or more users or groups. Optionally, a user with access to a node would have recursive access to all child nodes. * There is no all-knowing arbiter that can read and write any entry in the database. Not having an arbiter will complicates things quite a bit. * PKI is used so that a new password entry is associated with a list of users or groups, and is then encrypted with the target users' pubkeys. A pubkey lookup mechanism is needed. * Preferably have a distributed system, managed by distributed revision control. This precludes using filesystem semantics like permissions, acls, etc, and would instead require the use of a metadata index of sorts. * Preferably make the system usable without having to rely on a frontend: Running 'gpg -d *' would decrypt files encrypted with your pubkey. As far as I can tell, there exists no such thing -- possibly for very good reasons; see below. I've been thinking of how to implement this sort of system, like so: * Use one file per password, with a simple structure like: [ ], where : directory-style path to the entry, e.g. '/dns/resolver/res1' : user(s)/group(s) with access to the entry. This might have to include lookup details, such as ldap url or similar. : name of entry, e.g. 'root account' Name, username, password and comment are optional, to facilitate the creation of password-less branching nodes in the tree, solely for indicating user/group access (which then apply recursively). * Files have inconspicuous names, for example created by hashing the file contents, random characters, or a serial number. Possibly add random decoy files to discourage traffic analysis. Possibly gather all files in one tar or zip archive, which is again encrypted with everyone's pubkeys. Size is not a concern. * Creating a new entry would require inputting the user(s)/group(s) that should have access. This, together with the lookup/fetching of target user keys, is somewhat tricky. * Using something like Git would make revision control easy. On the other hand, it would make it possible for revoked users to regain information by fetching old revisions. This might preclude revision control altogether. * Revoking access for users that either leave or switch groups, would mean having to re-encrypt all entries where the user had access (and remove entries where the user had sole access). Without an all-knowing arbiter, this could also easily be a showstopper. * Having a simple curses-based interface would allow easy navigation of the tree, displaying only the entries that the user can access. A web interface would not work out, due to the use of pki. A standalone gui application could work, for the command line challenged. Any thoughts on this, especially the showstoppers? S. From hka at qbs.com.pl Fri Jul 27 14:44:59 2012 From: hka at qbs.com.pl (Hubert Kario) Date: Fri, 27 Jul 2012 14:44:59 +0200 Subject: [OT] Multi-user hierarchical password management via pki In-Reply-To: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> References: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> Message-ID: <3117998.Mt6KF9modE@k85hala03> On Friday 27 of July 2012 13:46:02 Sven Ulland wrote: > Is there such a thing as a multi-user, hierarchical, arbiter-less, > pki-based > password manager? I'm thinking specifically for use in a system > administration > context where you have multiple sub groups and cross-group roles that > have > access to different sets of passwords. I know about no such FLOSS system. passpack.com is good at sharing passwords, but it is very rudimentary in comparision to your requironments. I know that Hitachi makes "Identity Manger" that claims similar functionality to what you want, but I've not seen it, let alone use. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl From hka at qbs.com.pl Fri Jul 27 14:50:40 2012 From: hka at qbs.com.pl (Hubert Kario) Date: Fri, 27 Jul 2012 14:50:40 +0200 Subject: [OT] Multi-user hierarchical password management via pki In-Reply-To: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> References: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> Message-ID: <4570442.5rnXGCcuWg@k85hala03> On Friday 27 of July 2012 13:46:02 Sven Ulland wrote: > * Revoking access for users that either leave or switch groups, would > mean > having to re-encrypt all entries where the user had access (and > remove > entries where the user had sole access). Without an all-knowing > arbiter, > this could also easily be a showstopper. If you have PKI it's easy. All people that have access to an entry have this entry symmetric key encrypted using their public key. To change the symmetric key, you decrypt, select new key, encrypt key with public keys of all people that had access to the entry in the first place. It is no different than changing the data inside the entry... It requires usage of cryptographic primitives, not simple wrapers aroung gpg but it's completely doable. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2237 bytes Desc: not available URL: From Lists.gnupg at mephisto.fastmail.net Fri Jul 27 20:12:56 2012 From: Lists.gnupg at mephisto.fastmail.net (Kevin Kammer) Date: Fri, 27 Jul 2012 14:12:56 -0400 Subject: Mac OS X 10.8 and OpenPGP Cards In-Reply-To: References: <20120726193445.GA1612@clarus.mgh.harvard.edu> Message-ID: <20120727181256.GA1950@clarus.mgh.harvard.edu> On Fri, Jul 27, 2012 at 09:26:14AM +0100 Also sprach Nicholas Cole: > On Thu, Jul 26, 2012 at 8:34 PM, Kevin Kammer > wrote: > > ... > > > > I just upgraded from Mac OS X 10.7 to 10.8, and my ZeitControl cards, > > which were formerly working perfectly, are now inaccessible. > > > > ... > > If it is any consolation, it is working for me (Gemplus GemPC Reader) > Have you installed the smartcard libraries? > It has been so long since I had to mess with it (on my mac anyway) that I don't remember. Which libraries do you mean? It might jog my memory, or at least I can look to see if they're installed. I can say that up until yesterday, the libraries, daemons, etc, that were in place were fully functional. From richard.hoechenberger at gmail.com Fri Jul 27 20:45:51 2012 From: richard.hoechenberger at gmail.com (=?ISO-8859-1?Q?Richard_H=F6chenberger?=) Date: Fri, 27 Jul 2012 20:45:51 +0200 Subject: Mac OS X 10.8 and OpenPGP Cards In-Reply-To: <20120727181256.GA1950@clarus.mgh.harvard.edu> References: <20120726193445.GA1612@clarus.mgh.harvard.edu> <20120727181256.GA1950@clarus.mgh.harvard.edu> Message-ID: <5012E1DF.60603@gmail.com> On 27/7/2012 20:12, Kevin Kammer wrote: > It has been so long since I had to mess with it (on my mac anyway) that > I don't remember. Which libraries do you mean? I never had to install any additional libraries, at least not until 10.7.4. Don't know about ML though :) Richard From faramir.cl at gmail.com Sat Jul 28 03:27:38 2012 From: faramir.cl at gmail.com (Faramir) Date: Fri, 27 Jul 2012 21:27:38 -0400 Subject: AES vs. Serpent vs. Twofish (was Re: KeePass or any other password wallet to store and transport keys) In-Reply-To: <50111439.10309@adversary.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500C268B.8050001@gmail.com> <500C681C.2020201@sixdemonbag.org> <5010FA57.90909@adversary.org> <50110298.3010303@sixdemonbag.org> <50111439.10309@adversary.org> Message-ID: <5013400A.5080109@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 26-07-2012 5:56, Ben McGinnes escribi?: > On 26/07/12 6:40 PM, Robert J. Hansen wrote: ... >> For instance, I don't like Serpent very much on account of how >> complex it is. My rule of thumb is, "if I don't believe an >> undergraduate in computer science can understand this algorithm, >> how can I expect people to implement this algorithm correctly?" Lets hope people developing TrueCrypt have a graduated in computer science among them ;) ... > Interesting. Most of the things I've read on Serpent, which > admittedly isn't much, is about how it was not accepted for AES > because of the speed aspects rather than other aspects and that it > may be more secure. I *think* I remember B. Schneier said Serpent is the most secure from AES contest. Current AES is recommended because it is the standard, so, "no one gets fired for using AES" (like IBM), and for his money, he would use TwoFish (if we consider Schneier was uncomfortable with some things about AES that now are known to be not as strong as they were supposed to be, maybe TwoFish lacks those vulnerabilities... but might have other undiscovered issues. Good thing is, *if* they remain undiscovered, they won't be exploited). Anyway, one reason to cascade the 3 algorithms might be: Serpent, because it is the most secure. TwoFish, because it might lack the vulnerabilities AES has, and because we might be affraid Serpent was not implemented right. And AES, because it is the standard, and no one gets fired for chosing AES. Now, if we consider Serpent was rejected because its lack of speed, the 3 algos together must be like an arthritic snail... Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQE0AJAAoJEMV4f6PvczxA/dIH/0PI/mVXDIaPVIepybEPTwhu xEcTwm4g+1tpN7E55WdRoLIbA9tGvmEHSYk2Wt/fKhee0Txs/Aymnu/jhGL7Ikt0 24+Qjp5ZD3Z90Vmqppc9khBQiYI9i5MWnV5ZgiHejBNL/SI5wkHB/0AuV/Ck0KPO 4DEl+U5s/6uidcxmZGr3Xg74fCiOMzKSWhQ49j5rLuK3NhStcuUUpuUMj977Fuae jVsD6Nt38n7dCoNq2sUduFgWeBnvuO5z0Ms7OroCvqlpKgXQiCcdR6IRWIEZhAAi jGvoJfN/A+QpZ6S+xAq3dWecmS+O63j1Lp3laycMQfImotWYZi2mVs/xqQNkZHI= =RI9P -----END PGP SIGNATURE----- From faramir.cl at gmail.com Sat Jul 28 04:17:02 2012 From: faramir.cl at gmail.com (Faramir) Date: Fri, 27 Jul 2012 22:17:02 -0400 Subject: KeePass or any other password wallet to store and transport keys In-Reply-To: <20120726124340.GB1524@fritha.org> References: <1342799498.14477.140661104546589.6C120637@webmail.messagingengine.com> <500B1B3E.3020607@dougbarton.us> <1342913163.10115.140661105011441.3FDAEA35@webmail.messagingengine.com> <500B5B91.70607@dougbarton.us> <1342993879.29546.140661105277085.65BA97A9@webmail.messagingengine.com> <500C8BF2.70409@dougbarton.us> <1343000352.13464.140661105301033.34AF28FE@webmail.messagingengine.com> <500F4A78.4050301@gmail.com> <1343219372.1230.140661106444097.0A9CE7D2@webmail.messagingengine.com> <50109DC2.9040709@gmail.com> <20120726124340.GB1524@fritha.org> Message-ID: <50134B9E.6070905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 26-07-2012 8:43, Heinz Diehl escribi?: > On 26.07.2012, Faramir wrote: > >>> That's security through obscurity assuming the other one won't >>> know where to search for the key, which is not stored with ... >> Not right, if your secret key is protected by a passphrase (or >> strong password), it doesn't matter if the attacker know where to >> find it. > > It does matter. Because the software which has generated the key > can be flawed, and thus can have generated a flawed key. Nobody has > to know about such flaws, it's quite likely that an attacker > chooses not to publicate information about that, with the effect > that he/she can use the security hole longer (maybe forever). If > it's reported, it will be fixed immediately. Wait, now I'm lost here... we were talking about how to prevent an attacker from getting an usable private key, so I don't see how the quality of the key has anything to do with it. >> Actually, the attacked is very likely to know where it is, since >> probably it will be at the default folder. > > This is why smartcards exist. Well, yes, but we were talking about keys not stored on smartcards, but on normal storage devices (like hdd or USB flash memory). Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQE0ueAAoJEMV4f6PvczxAJVQH/3cz7MZ3rIdQVDzCxhhWxfv4 e+9kSuiB465UqeI/aFb7weEDVTs5dVYzhHsZ7VU6dx4LE4KI2m2M/vkscqpRWZMj Srs+PpP8yBbO/f6ibBqYfNaZX53gtMYJtdIRHP3bQUvCj3CV9FLYG8PDHBLosY2F 0rtuoS6sOitUcDZGl6EXCHk9gXxXLRzH7IWYoE1PSIKvm+ZQQ99RyE2NBwDPb41a RsK/xD8S8ZYX692Dfi9TZnlUoe0XnGsu6yiWaQAqlY3APPckVU84Uh2VhJRHu7Rk MJmYbMUt2gWKVXkiNrYtuOV2v3dRBDSYRCohCNSe82Acq8zNa8YiiZstcCpAUWE= =fHSd -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sat Jul 28 16:53:29 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 28 Jul 2012 10:53:29 -0400 Subject: [OT] Multi-user hierarchical password management via pki In-Reply-To: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> References: <3f2f3e0b0938c15a6d971d5698ab954d@ulrik.uio.no> Message-ID: <5013FCE9.9000208@fifthhorseman.net> On 07/27/2012 07:46 AM, Sven Ulland wrote: > Is there such a thing as a multi-user, hierarchical, arbiter-less, > pki-based > password manager? I'm thinking specifically for use in a system > administration > context where you have multiple sub groups and cross-group roles that have > access to different sets of passwords. I don't think this precisely meets all of your specs, but it comes remarkably close: https://keyringer.sarava.org/ you can get the source here: git://git.sarava.org/keyringer I've cc'ed the lead author (Silvio Rhatto) here, in case he wants to follow up. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From hardkor.info at gmail.com Sat Jul 28 21:20:18 2012 From: hardkor.info at gmail.com (HardKor) Date: Sat, 28 Jul 2012 21:20:18 +0200 Subject: New GnuPG mirror Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I just set up a mirror of the GnuPG website. http://gpg.hardkor.info/ I update it automaticly every 12 hours with a cron task. Could you add it to your mirrors list ? HardKor - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.12 (GNU/Linux) mQINBE8SzTkBEADn5drNTXGAHDjg4yskBeyJ7zwfGUW4GwZ0UyBEEaedaDVXpPLB MjhaEjSLlF6XC/pK6T/h3bUSLDzB+cnJtPqnggkKbEkw4AdKQZATg5BXB5LoX6rV EwCoTbGyqwloZHWY8qd15qjKPXtsZYU9SNTX9cpdObxknQhbZulxv7CVDTaLwIN7 P1GjROyOpOSiMvUM7stnJeIKEyjoGUuXpG13f7YoZDokSALRneXlm6tqbxM+9aXu JtSVNt5cw9iHPuKFf8lkln856BmdKl3FNkSArRXilqfh/ZbpOPeUoibHLW2612/x tTzQkYMTa/t1yGPtUZMzFUk+IRLW2hKoN/AR2aSnlIOkDmqZnL/wNKxwKJkCkft0 hBZbcE351FBK3E0XC3Oa1pO4YWhBbRVx0bdLH3zPnDNzd621EskKtL+2eKEM4JUj oy+7/VwxUUWJ9mtFujy7S6c8v/+IGaQsmS6VDryjfLTYn93VNcNmTthZAeIQ5ZGu 6PN4rBD7g7W9/hyPIMccg76X9AppQOlWQ0kUI3tkLzzBrfv1V0P9bfuCe3eYGMyc eXZAinrEow1hkEt6geUZF82uJbs+ShPfBEET91fYGrzW2XAl/OpMDiUWOER0870t rURbdd9w5DxyZi0LVl4cMpH13TRCHbqXgdGLRdUGe0VjGva81IZPxUhWEQARAQAB tB5oYXJka29yIChodHRwOi8vaGFyZGtvci5pbmZvLymJAjgEEwECACIFAk8SzTkC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHT1+HVtNEX5+FEQALN6n3DB BQsPGE7uQNIXUsakOo2H6V+hHoYMBBDJR1aaRxFU3AO4y5Vm3655ksyJicTrJnNU 5n3QURwt0WKZ9nKt1qzeqH28ZwibRVkqBkjoYgOo3G2IbtIfdouK64xd0/wr6uqy L8/t7Bd9YPnCHWwSxFlDF+9pKeS1SRQnsBv6vRD4eg9Teiz0T/nDPeKrh7rvGHL2 1CHW1kjenH8UVPUv6q0Ucmu5ocUQSIACIGyihE95uoypkPXXjie0a+UVITLf0gKg ySZCDDtYpY5D4ZNSDTz49NFzJHSrc7cViD9muufOrq69wBtBY82E7I9NA/edpSOy O7Ez0BbWkR3GDXMGbugMf0aJj0LaiPCDW26u2vLQW9GtUHwwTMj9NZZ8nBhbiMWh BYJhiDnL3ES+ywYwnYodUsF2ZHmjZateC9vh5Nyfd16uF6riFOIYKhnxv9SyQQuD weTttkROtoGRRJ6IJRR4eotStSH2BwjFA1Xgemz060ylrFXcIYl98e1mXi/EDFwT 1mhpl49hOQrHrHiS5aVtM6wJ3H2MIQT6GRQ42Itk6t+82nyGH1mgxwBDjx7wrTzS SbV11/9MQJeNZX6kIiDvtiEolKDz+f9hR/5mjMGWQe7tdAninM1420ZtivhbtSiw qzrA0LS+QH2+Itms9QDIpL9p/8IVNppCl//NuQQNBE8SzYcQEADVzXlq5XtSX8cC X8nNfSeTCXbIxZxGJapyuJR8hxgzvzTOsyTZgOFdIp4aE3V1ayCQQtFmeqykbJkP XKY6AwAFL/w+YmWm49bS4hRnNNCJQeFhDio1f2n5jxDy8TIR5YFUpTs/9I9Hc2oU Lt+P20R/lBM6ivkiVtAYKTNcgXa0a52HywI0hosC9r4aZ3EVFPKPwSTwax9jOO1I iPFXrDD/jl0n0U+Bm8DEzjWo8Uoi+ixYGa7QFiQp9C0H2mnYh4sbU9jRk0xbmCgu eMWr5BMwuGghoMYDmtmkb6QAg0zD09y+2Be15WXOBUWQD2MYSrgrSJzMiOpgSwPH ZJ0j3GLUnCE0AwMT8T8nhUHUmjuEr4R6DEe9h91EOvJUIryqQjsLIQJj+DK/CwB5 1LMSY3bpeWBMAxTwtX211f3e9bMgsvX0cgh66E0Ap606H7vABXahimoDt+74YR+y LPUmSyoz5zOwi+P6S7syIwDXPL0XISwpHVP240NXKpM+nDm6jYx3pmj7JjJ1nAEY cjEuXO5Eu1OhK9N5KM7yIBliqR4nTiN/rOp2DwvRSFDdt5Veku+SclgboJOrFq0a Xsa/ywWWZBDoQ/Vr/KSn+UaCOvE4z74YpJ8LuUyE3q571KKC5MFUmht7eeIELpZm Jxm4rrUwfNKWSNttVvqPWcRSePylbwADBQ/+ObM3hQg0nquDVjtTvpW77m6EuUSU bUtpQE7Wzfb2wsY8yYdS/NmjrSZ+wweYg5IhobUD9l2fXYm7EI9j3V7NFpGqXHYN PNvRVNTiBnchIxQ2dsHo9RPDzKuPHp7y1S0dNuvqmc9OO+9xrU2f2JTExEn3cuAG ZXjcbvL974Z2b56nI4UjLU0OeADAVT24JCLeE4x8ci2qqTkq6MA7hX/jqbKZ095S bRntRQlNBpoSD/06pWD19CUKAUo8bo+yHRRaXmhkQq9juApEUSfPMaUz/uDZU2Aq kMFKMmuW1azKCAiv0qOApSULpf6tfErcoHflAVb2ThYKxbHqC3keL5S0xxcR1psm C2llPEB2USR0eKCxi3mzzbKkfAj9ED3AkucpR47Ei3OeP4YdWkNNFcyo0Dptepj8 WnNu/uXujWpEG/DZbWfh3LjJy3LghmjKNKZ4XDAPdP7a+/pctIlwAJRl1sYJBVY9 AAxcrAp9jAjO1QoWAQ1cd+M/5j8+vd+S/i3T/DN7rRY9gJmyKviGFWISuMSmxscj HpPpNfpDXRFeFv9zMHv7RnbTbxVnXbn0Byc6no7vatHyep4GdpGZ0xHB148c/mY5 SAEICc7uKCc0Kpc3LMAO62CvX8xHkZiqxeN+dJ5oLXmedojbzPsv5zY+Zch12WA4 VLhyUNdMcMTrkvOJAh8EGAECAAkFAk8SzYcCGwwACgkQdPX4dW00RflI5BAA19y+ TnahNKaZ+0G76MdFgDK2Jj2uxcPEA/YXaJ+/Gk2ePRVkdboqhkrKW9U9qDKDgmM5 TWKHwE9NVhhc1dq3O2fE3EedKxNXEevXxQMgJCgn/AAL8qXOM7i+KaVkeoL1TPJd 9dRJnixxvgoM2UfH49hnO8D67Qgi38yin1uM5knvz3BodSiQRrjh26Xgq3YAxmnh uZQLP1lvh4uRqfUibFq1O+rmI04hMYJsnMHy7AWQDj9yb5LjDh2DlkS0czk3ZHRc ZwSFwV0p/2X0d29kf6uAFo/0Fr+I3qzixFkDz3bFmPtsyDS9BwJOZlbe248+jahr QdeekGvcvMULWXUBqGBWzJ2q0vCw3PONFaRZt6qUrBPGl+KFRBC9NBgSPPVxHrTs BfAirtihnZiqJRwR1KtJh9DH2XrHtzqF3wYx3wvG/WMtn4R8ZxSqcfbufVSVWUeM xStfUUwgYnFLuzfIbaTv3DwPyDzfbETgYhX44CpdFRmY34woOp6vuOszE3wnP6kS BlECwauJ8FZwNZUbFfi2e1DzzYFmgEYiDOd5v66bVkztTQK7MexJDMrCs2O3fJJc MyS8IED/8twQdCZPGWQd5KUXTz5iJxexNeQb3eGocckmk8X9gv9xyLz+2/PcBeMH zhHaw53PckkTfsyF8IwfH/Z81ko9RvCId6sJ+uk= =BIDL - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQFDtMAAoJEHT1+HVtNEX58S4QAKzxSl33Vo2qszesEAfDakaF EozGKuU+R9nRlVHkIQ9zaK/KsUtquH2ZgioBG5Wct/h1/+quhp0ODDeb6a4erkfw ReDNhqkokQ/FybMAtfIboRl+Ej9X/hwQqn2Ra4LSHKNF4ikSWJVtIw4YBQcZmxWf nugjpbpF4iiz9cWXstGo5bHW2QHompIp/SUCEAkc2Ko0ZY+h2EhIVRsK9Jpzl1Pz p9S8wgRz/rBmnYeq06e8U/es3gbfGOsjYbtRkHjMafGdrMRj1OO+z8bGTZ8Uobhw RkO/Hyz8eNbgaqnPMfsDy5eFrlLJl5eEFpntwkCsfLq2N14Ps0VjxzOx5jpbns1i Cst0mUVErtnLIjlAtH2MF6owunrx2S24xSr4yM4u7Qg1MzQfjjiXJNS3IjujG7h6 pTbk5l0N0G0dDbKv+03kFmYR6+9dOt5A7yeGxh5Br8B/rxqRVCXIedD4AK2bfMZG anFAqHpXhyRxeKWEU73WwNsiC3hFtxu7MokVhD2SWU6OkhF3/xmEnliYdlBUto77 4CGYDxFpsNNivkk3pIO+yf8XTjNDmAGKn6bOZfber8I43ilBoItwDeoEJhhJenmm St23RcvHw8WJl2T3OQ78HoBrDxYrY8Rzn1rLZv4VBN3XqgDUDvmZNuunuV5Al3AZ ucz1aJxQf/m8zsiiHABp =4M3u -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at 16systems.com Sat Jul 28 20:18:19 2012 From: brad at 16systems.com (Brad Tilley) Date: Sat, 28 Jul 2012 14:18:19 -0400 (EDT) Subject: Possible bug in gpg? Message-ID: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> Hi, I have a symmetrically encrypted pgp file here: http://16s.us/word_machine/downloads/pgp-easy.tgz.pgp gpg will accept the three characters !=X as the password and exit with a return status of 0 (although it does not actually decrypt the file): $ gpg -d pgp-easy.tgz.pgp gpg: CAST5 encrypted data gpg: encrypted with 1 passphrase gpg: WARNING: message was not integrity protected $ echo $? 0 !=X is not the plaintext password that was used to encrypt the file. I was hoping someone on the list might be able to help me understand why this might happen. Could it be a bug in gpg, or OpenPGP itself? Here is my gpg version: $ gpg --version gpg (GnuPG) 1.4.12 Here is --list-packets: $ gpg --list-packets pgp-easy.tgz.pgp :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 8dd17929c3935452, count 65536 (96) gpg: CAST5 encrypted data :encrypted data packet: length: unknown gpg: encrypted with 1 passphrase gpg: WARNING: message was not integrity protected I don't yet know the actual plaintext password or the exact commands/program used to encrypt the file, but I should know in a few days. This is a file that's apart of the defcon password cracking contest and I came across this and wanted to mention it here. I'm not subscribed to this list, so please cc me if you want to reach me. Thanks, Brad From laurent.jumet at skynet.be Sun Jul 29 00:46:46 2012 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sun, 29 Jul 2012 00:46:46 +0200 Subject: Possible bug in gpg? In-Reply-To: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> Message-ID: Hello Brad ! "Brad Tilley" wrote: > I have a symmetrically encrypted pgp file here: > http://16s.us/word_machine/downloads/pgp-easy.tgz.pgp > gpg will accept the three characters !=X as the password and exit with a > return status of 0 (although it does not actually decrypt the file): === Begin Windows Clipboard === [C:\TEMP]gpg -v -v -v pgp-easy.tgz.pgp gpg: using character set `CP858' :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 8dd17929c3935452, count 65536 (96) gpg: CAST5 encrypted data :encrypted data packet: length: unknown gpg: encrypted with 1 passphrase gpg: decryption okay === End Windows Clipboard === -- Laurent Jumet KeyID: 0xCFAF704C From ben at adversary.org Sun Jul 29 03:54:21 2012 From: ben at adversary.org (Ben McGinnes) Date: Sun, 29 Jul 2012 11:54:21 +1000 Subject: Possible bug in gpg? In-Reply-To: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> Message-ID: <501497CD.4070609@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29/07/12 4:18 AM, Brad Tilley wrote: > Hi, > > I have a symmetrically encrypted pgp file here: > > http://16s.us/word_machine/downloads/pgp-easy.tgz.pgp > > gpg will accept the three characters !=X as the password and exit > with a return status of 0 (although it does not actually decrypt > the file): > > $ gpg -d pgp-easy.tgz.pgp gpg: CAST5 encrypted data gpg: encrypted > with 1 passphrase gpg: WARNING: message was not integrity > protected Yep, I got essentially the same thing: bash-3.2$ gpg -vvv pgp-easy.tgz.pgp gpg: using character set `utf-8' :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 8dd17929c3935452, count 65536 (96) gpg: CAST5 encrypted data :encrypted data packet: length: unknown gpg: encrypted with 1 passphrase gpg: decryption okay gpg: WARNING: message was not integrity protected bash-3.2$ pgpdump pgp-easy.tgz.pgp Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes) New version(4) Sym alg - CAST5(sym 3) Iterated and salted string-to-key(s2k 3): Hash alg - SHA1(hash 2) Salt - 8d d1 79 29 c3 93 54 52 Count - 65536(coded count 96) New: Symmetrically Encrypted Data Packet(tag 9)(512 bytes) partial start Encrypted data [sym alg is specified in sym-key encrypted session key] New: (13 bytes) partial end bash-3.2$ > !=X is not the plaintext password that was used to encrypt the > file. I was hoping someone on the list might be able to help me > understand why this might happen. Could it be a bug in gpg, or > OpenPGP itself? Here is my gpg version: I symmetrically encrypted another file with CAST5 (same version of GPG as you) and tried the same trick. The !=X string did not produce the the same message. Instead I received the expected "decryption failed: bad key" message. > I don't yet know the actual plaintext password or the exact > commands/program used to encrypt the file, but I should know in a > few days. This is a file that's apart of the defcon password > cracking contest and I came across this and wanted to mention it > here. Ah. I suspect that it will either be something weird to do with whatever software was used to encrypt the file or someone has found a way to be sneaky with it. Either way, when all is revealed please post a follow-up. > I'm not subscribed to this list, so please cc me if you want to > reach me. Sure. There has only been one other response which it does not appear was CC'd to you, but it didn't shed any light either. Maybe someone else here will have some insight. Regards, Ben -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJQFJfMAAoJEH/y03E1x1U8LjMMALwYzbh4l+8iXMeb34twWMpL jOp/XOYwn47ybTaa/vx7F+f0fX/JJAP3pUXoRF5RwSKDv3tMie1qGL4Dfi8QCx8G eY8q2ahz+hDnzoa95tLx3cMnFaz/D4uGpFXvolyS1Ml0V1my+OXLcf9kta9w4qjD h+GXrF4atgeEykDQIDJAcqAYcAg/Pmae7AHSM7O8a1HWgwr1tChj1huaOJfRVszI 1tDp30S1M+ub+YPCXiU1o0LVCbioIPkvmSGFgqBI36+VTglfHvZv+sI7uSO+gszz tjm27p8d5ZICujD8h57x2veLnrMbHsgv109cw6q3y6bQYU/bjaXp45Ba2INKLwKW 9+2DTpZuX4Q+eQ15o3YbWFjgcLTv378nO/JfQGLLNYx7JoJ3wz7vIGofUHEt5ek7 aWMXnkGrOXJUYJMTlS4PpsFx3fI7tqNQ9d4Df8MEIjiHp0ha2WaBOy/0AKtxBVFH 14QSgvgG9jWKprfFcHz8nIv/kk48M3XVscyz6TFAtA== =XfJ8 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Jul 29 06:48:25 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 29 Jul 2012 00:48:25 -0400 Subject: Possible bug in gpg? In-Reply-To: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> Message-ID: <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> On Jul 28, 2012, at 2:18 PM, Brad Tilley wrote: > Hi, > > I have a symmetrically encrypted pgp file here: > > http://16s.us/word_machine/downloads/pgp-easy.tgz.pgp > > gpg will accept the three characters !=X as the password and exit with a > return status of 0 (although it does not actually decrypt the file): > > $ gpg -d pgp-easy.tgz.pgp > gpg: CAST5 encrypted data > gpg: encrypted with 1 passphrase > gpg: WARNING: message was not integrity protected > > $ echo $? > 0 > > !=X is not the plaintext password that was used to encrypt the file. I was > hoping someone on the list might be able to help me understand why this > might happen. Could it be a bug in gpg, or OpenPGP itself? Here is my gpg > version: I haven't examined this file extensively, but assuming it isn't corrupt, or specifically engineered to be not decryptable in some way, I'm suspecting this is an example of a quick check failure. In OpenPGP, a message is made up of different packets. In your case you have a symmetric key encrypted session key packet (essentially instructions on how to mangle the passphrase into a session key), followed by an encrypted data packet, which is encrypted to the session key that results from the first packet. Normally, when decrypting, the client will read the first packet, prompt the user for a passphrase, and mangle the passphrase into a session key. Then it reads the second packet, and uses the session key to decrypt the data. However, people being people, they can easily typo the passphrase, and given the method above, if the passphrase is wrong, the session key will be wrong, and the data decrypted will be gibberish. To combat this, OpenPGP has two "quick check" bytes in the encrypted data packet. Basically, they're a repetition of two random bytes from earlier in the message. The idea is that if the session key is wrong (i.e. the passphrase is wrong), the original random bytes won't match their repetition, and the client can immediately say "Wrong passphrase!" rather than blithely continue and potentially decrypt lots of data that won't turn out to be valid. The practical upshot of this design is that while it works most of the time (in that virtually all incorrect passwords will be immediately flagged as such), each symmetrically encrypted message has the chance for other, incorrect, passphrases that nevertheless will pass the quick check. Obviously, these cannot decrypt the message, but they mangle into (invalid) session keys that just so happen to decrypt the data so that the 16-bit quick check matches, allowing the client to proceed, and decrypt (incorrectly) the rest of the data. Usually this fails fairly quickly afterwards as the data decrypted is not valid OpenPGP structures, so the client will stop with an error message about being unable to read the file. In this particular case, the !=X passphrase passes the quick check, and the incorrectly decrypted data happens to look like a packet of packet type 0, of length 942141745. GPG ignores the invalid packet (there is no packet type 0), and so no output is generated. So, assuming my guess is right, it's not a bug in OpenPGP or GnuPG (though perhaps giving an error when it saw the packet type of 0 would have been better), but a pretty unlikely confluence of events. How did you come up with the !=X passphrase? Exhaustive search? I'd be curious to find out what the real password is, once it is revealed. Incidentally, these quick check bytes were used as the basis for an ingenious attack against OpenPGP a few years ago. See http://eprint.iacr.org/2005/033.pdf David From brad at 16systems.com Sun Jul 29 05:26:59 2012 From: brad at 16systems.com (Brad Tilley) Date: Sat, 28 Jul 2012 23:26:59 -0400 (EDT) Subject: Possible bug in gpg? In-Reply-To: <501497CD.4070609@adversary.org> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <501497CD.4070609@adversary.org> Message-ID: <60662.108.4.178.254.1343532419.squirrel@webmail.tuffmail.net> >> Hi, >> I have a symmetrically encrypted pgp file here: >> http://16s.us/word_machine/downloads/pgp-easy.tgz.pgp >> gpg will accept the three characters !=X as the password and exit with a return status of 0 (although it does not actually decrypt the file): >> $ gpg -d pgp-easy.tgz.pgp gpg: CAST5 encrypted data gpg: encrypted with 1 passphrase gpg: WARNING: message was not integrity >> protected > > Yep, I got essentially the same thing: > > bash-3.2$ gpg -vvv pgp-easy.tgz.pgp > gpg: using character set `utf-8' > :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 > salt 8dd17929c3935452, count 65536 (96) > gpg: CAST5 encrypted data > :encrypted data packet: > length: unknown > gpg: encrypted with 1 passphrase > gpg: decryption okay > gpg: WARNING: message was not integrity protected > bash-3.2$ pgpdump pgp-easy.tgz.pgp > Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes) > New version(4) > Sym alg - CAST5(sym 3) > Iterated and salted string-to-key(s2k 3): > Hash alg - SHA1(hash 2) > Salt - 8d d1 79 29 c3 93 54 52 > Count - 65536(coded count 96) > New: Symmetrically Encrypted Data Packet(tag 9)(512 bytes) partial start > Encrypted data [sym alg is specified in sym-key encrypted session key] > New: (13 bytes) partial end > bash-3.2$ > >> !=X is not the plaintext password that was used to encrypt the >> file. I was hoping someone on the list might be able to help me understand why this might happen. Could it be a bug in gpg, or >> OpenPGP itself? Here is my gpg version: > > I symmetrically encrypted another file with CAST5 (same version of GPG as you) and tried the same trick. The !=X string did not produce the the same message. Instead I received the expected "decryption failed: bad key" message. > >> I don't yet know the actual plaintext password or the exact >> commands/program used to encrypt the file, but I should know in a few days. This is a file that's apart of the defcon password >> cracking contest and I came across this and wanted to mention it here. > > Ah. I suspect that it will either be something weird to do with whatever software was used to encrypt the file or someone has found a way to be sneaky with it. Either way, when all is revealed please post a follow-up. > >> I'm not subscribed to this list, so please cc me if you want to reach me. > > Sure. There has only been one other response which it does not appear was CC'd to you, but it didn't shed any light either. > > Maybe someone else here will have some insight. > > > Regards, > Ben --- Thanks for the reply Ben, I've encountered several other plaintext strings that cause the same behavior. Here's another one: K02&10&![ It seems to work (gpg -d accepts the string and exits with status 0) but again the data are not decrypted. Someone cracked this, so we should know what the actual plaintext is soon. Thanks again, Brad From johanw at vulcan.xs4all.nl Sun Jul 29 15:29:45 2012 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 29 Jul 2012 15:29:45 +0200 Subject: Possible bug in gpg? In-Reply-To: <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> Message-ID: <50153AC9.9070602@vulcan.xs4all.nl> On 29-07-2012 6:48, David Shaw wrote: > To combat this, OpenPGP has two "quick check" bytes in the encrypted data packet. > Basically, they're a repetition of two random bytes from earlier in the message. Does this not lead to a possible known-plaintext attack on gpg? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Sun Jul 29 16:08:08 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 29 Jul 2012 10:08:08 -0400 Subject: Possible bug in gpg? In-Reply-To: <50153AC9.9070602@vulcan.xs4all.nl> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> <50153AC9.9070602@vulcan.xs4all.nl> Message-ID: <501543C8.1060308@sixdemonbag.org> On 7/29/2012 9:29 AM, Johan Wevers wrote: > Does this not lead to a possible known-plaintext attack on gpg? At risk of seeming condescending -- There is no such thing as a known-plaintext attack on GnuPG. There are only known-plaintext attacks against the algorithms in GnuPG. Since there are no practical known-plaintext attacks against any of the algorithms in GnuPG, we can conclude this feature does not facilitate any such attack. From dshaw at jabberwocky.com Sun Jul 29 18:11:54 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 29 Jul 2012 12:11:54 -0400 Subject: Possible bug in gpg? In-Reply-To: <50153AC9.9070602@vulcan.xs4all.nl> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> <50153AC9.9070602@vulcan.xs4all.nl> Message-ID: On Jul 29, 2012, at 9:29 AM, Johan Wevers wrote: > On 29-07-2012 6:48, David Shaw wrote: > >> To combat this, OpenPGP has two "quick check" bytes in the encrypted data packet. >> Basically, they're a repetition of two random bytes from earlier in > the message. > > Does this not lead to a possible known-plaintext attack on gpg? The attack a few years ago was chosen-ciphertext. For those who don't recall, if you have a system that will decrypt messages submitted to it, and will return an error if the message doesn't decrypt (i.e. you've made an oracle), you can use this attack to get 2 bytes out of every cipher block in 2^15 attempts on average, per block. It's not necessary for the attack, but if you know the first 2 bytes of the plaintext that helps start the chain (and in OpenPGP you can virtually always guess the contents of the first 2 bytes). This is not a weakness of the cipher in question (it applies to all OpenPGP ciphers), but is due to the OpenPGP CFB "stutter" of the quick check. Read the whole paper at http://eprint.iacr.org/2005/033.pdf It's interesting work. This happened before RFC-4880 was published, so there is some discussion of it in there as well. It is why GnuPG (and possibly PGP - I don't recall offhand) ignores the quick check bytes when decrypting a public key encrypted message. We do still use them for symmetric messages for obvious reasons, which is why the original poster saw the oddity he did. I'm guessing he set up a brute force password cracker for that message and was surprised to see just how many passphrases "succeeded", but didn't manage to decrypt the message. David From jeroen at budts.be Sun Jul 29 21:39:08 2012 From: jeroen at budts.be (Jeroen Budts) Date: Sun, 29 Jul 2012 21:39:08 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <87txwwcfz4.fsf@vigenere.g10code.de> References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> <500EFFCF.3070206@budts.be> <87txwwcfz4.fsf@vigenere.g10code.de> Message-ID: <5015915C.7060801@budts.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/25/2012 12:04 PM, Werner Koch wrote: > On Tue, 24 Jul 2012 22:04, jeroen at budts.be said: > >> apparently they didn't work. Now I completely disabled 'Launch >> GNOME services on startup' in XFCE so gnome-keyring is not >> started anymore. Now I get the correct output from the above >> command. > > Please complain on the xfce and gnome lists and tell them they > should stop hijacking gpg-agent - at least by default. In fact I think for most users their ssh-agent implementation is rather nice. It completely removes the need to manually use ssh-add and just makes it work out-of-the-box. That they also implement gpg-agent similarly seems logical to give the user the exact same user-experience. Under XFCE the GNOME services are disabled by default, but comming from GNOME enabled them when I switched to XFCE (running away from GNOME 3) >> What I really wanted to accomplish here is to use my GPG >> authentication subkey for SSH authentication, without having to >> use an SSH-key at all. But it is still not clear to me how this >> can be accomplished, if possible at all? > > With 2.1-betaX it is easy to do. With older version you need > probably need to use gpgkey2ssh. But the latter is not weel > documented and frankly I have not used it at all. That seems very easy and interesting indeed. I understand now how to enable a GPG key for SSH with gpg-agent 2.1. What I do not yet understand is how would add your public key to the authorized_keys file on the server? Wouldn't the gpgkey2ssh-script still be needed for this? Or can gnupg output the public key in the correct format? Oh and one other small question: what exactly is a 'keygrip'? Why aren't the regular key-ids used for this? thanks for your help! Jeroen - -- website: http://budts.be/ - twitter: @teranex ___________________________________ Registered Linux User #482240 - GetFirefox.com - ubuntu.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCAAGBQJQFZFXAAoJEBrqc/v4ufiMBSkP/ieC0ytn7kvxhGMCMeMwSssq owDtnnd/DoVEtl60XlYdmdgHeVk3Mqr3cWRnsskrF8S0j19m39AD/3kzoA9bzkvs vnHz8rQtePvu6R+puoAaMNXFgFqeKVn5wXuJgIpgwcF3WTW2VRmPhfSQrkvY7Khv IM2zZi0oU3RnzuS8tcZizvMHNxYmaB0LUcus5XHEtUfCsSl1ldBemVGCIVrPtqd9 VJfqPAtaD8N+/ZGPkY//OapetfCKZ7gc36LeulvMXwdn7XbIA1NQVEGWyO4C8I5I MKqG75XmClwyGaDJw9mdOMKFYTcQ82OeHYQQq+TN6SQRsODaGAFjvR/W/XhIkkOy Yss+Y6n1WGx4zS+RNpAck+zLArcUTNLtiE23hlJpNX0ev4VjdBIf/G4+y8Eg+heA 84omR7PV7+NUZTTs36ISwfWGkr6fTrHeQDrRj3esrO1caxc6CZJwPvFVMPeC+SOd 2Fk9/Ro85yY2/2wApkowUqseggTUbGfQp0FYDsFxPyEmUH2kP67iy/zrxyUS2IJi l45+JrFbqfMiE7JxrBgYtklpcnI4cF2AQGFk415n5lo6kkkXAfSBCBhDwUn7O2Cr h30DVICZQzDcIy/FreDmxBLExWfgbiktCqtZSzOM4tI3PkSW7pk1JcF3PfbAvytA 4+/ZkIES6iPpeyobJGEU =FC+u -----END PGP SIGNATURE----- From Lists.gnupg at mephisto.fastmail.net Sun Jul 29 23:06:49 2012 From: Lists.gnupg at mephisto.fastmail.net (Kevin Kammer) Date: Sun, 29 Jul 2012 17:06:49 -0400 Subject: Mac OS X 10.8 and OpenPGP Cards In-Reply-To: <5012E1DF.60603@gmail.com> References: <20120726193445.GA1612@clarus.mgh.harvard.edu> <20120727181256.GA1950@clarus.mgh.harvard.edu> <5012E1DF.60603@gmail.com> Message-ID: <20120729210649.GA15330@shadowman.smellysneakers.net> On Fri, Jul 27, 2012 at 08:45:51PM +0200 Also sprach Richard H?chenberger: > On 27/7/2012 20:12, Kevin Kammer wrote: > > It has been so long since I had to mess with it (on my mac anyway) that > > I don't remember. Which libraries do you mean? > > I never had to install any additional libraries, at least not until > 10.7.4. Don't know about ML though :) > My recollection is that I have never had to either, and Gemalto's own site indicates that, at least through 10.7 (they don't have any information posted on 10.8 yet), OS X has built-in support for their card readers. However, all this talk of libraries would seem to be barking up the wrong tree. I don't really think it is a lack of libraries or drivers that is the problem. I have noted that the card works somewhat under certain circumstances. Most notably, GnuPG 1.x appears to be able to access the card. Problems crop up with GnuPG 2, gpgme, and gpg-agent. I don't see how any application would be able to access the card at all if the libraries/drivers were not in place. From wk at gnupg.org Mon Jul 30 11:50:43 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jul 2012 11:50:43 +0200 Subject: GPG key to authenticate to SSH? In-Reply-To: <5015915C.7060801@budts.be> (Jeroen Budts's message of "Sun, 29 Jul 2012 21:39:08 +0200") References: <500C5A05.5050209@budts.be> <87r4s2hpnu.fsf@vigenere.g10code.de> <500EFFCF.3070206@budts.be> <87txwwcfz4.fsf@vigenere.g10code.de> <5015915C.7060801@budts.be> Message-ID: <874nop8tn0.fsf@vigenere.g10code.de> On Sun, 29 Jul 2012 21:39, jeroen at budts.be said: > enable a GPG key for SSH with gpg-agent 2.1. What I do not yet > understand is how would add your public key to the authorized_keys > file on the server? Wouldn't the gpgkey2ssh-script still be needed for ssh-add -L (capital L) prints the public key as retrieved from gpg-agent. > Oh and one other small question: what exactly is a 'keygrip'? Why That is a protocol neutral way to identify a public key. It is a hash over the actual public key parameters. It is GnuPG specific but for example, pkcs#15 uses a similar technique. To compute it, you should use the respective Libgcrypt function. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From brad at 16systems.com Sun Jul 29 14:47:48 2012 From: brad at 16systems.com (Brad Tilley) Date: Sun, 29 Jul 2012 08:47:48 -0400 (EDT) Subject: Possible bug in gpg? In-Reply-To: <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> Message-ID: <48285.108.4.178.254.1343566068.squirrel@webmail.tuffmail.net> Thanks for the reply David. The file was actually cracked so we'll know the plaintext sometime soon, although that may likely matter not. > However, people being people, they can easily typo the passphrase, and > given the method above, if the passphrase is wrong, the session key will > be wrong, and the data decrypted will be gibberish. To combat this, > OpenPGP has two "quick check" bytes in the encrypted data packet. > Basically, they're a repetition of two random bytes from earlier in the > message. The idea is that if the session key is wrong (i.e. the > passphrase is wrong), the original random bytes won't match their > repetition, and the client can immediately say "Wrong passphrase!" rather > than blithely continue and potentially decrypt lots of data that won't > turn out to be valid. That seems like a reasonable check to make in most cases. I know that symmetric-key algorithms will happily output garbage when the wrong password is used and that may confuse some people, but then again, some others may actually prefer that. If I was expecting a pdf file (upon successful decryption) and there was no pdf header up front (only randomish looking bytes all through the file), then that would be a decent indication, to me, that the bytes I saw were not actually decrypted. > The practical upshot of this design is that while it works most of the > time (in that virtually all incorrect passwords will be immediately > flagged as such), each symmetrically encrypted message has the chance for > other, incorrect, passphrases that nevertheless will pass the quick check. > Obviously, these cannot decrypt the message, but they mangle into > (invalid) session keys that just so happen to decrypt the data so that the > 16-bit quick check matches, allowing the client to proceed, and decrypt > (incorrectly) the rest of the data. Usually this fails fairly quickly > afterwards as the data decrypted is not valid OpenPGP structures, so the > client will stop with an error message about being unable to read the > file. > > In this particular case, the !=X passphrase passes the quick check, and > the incorrectly decrypted data happens to look like a packet of packet > type 0, of length 942141745. GPG ignores the invalid packet (there is no > packet type 0), and so no output is generated. > > So, assuming my guess is right, it's not a bug in OpenPGP or GnuPG (though > perhaps giving an error when it saw the packet type of 0 would have been > better), but a pretty unlikely confluence of events. How did you come up > with the !=X passphrase? Exhaustive search? I'd be curious to find out > what the real password is, once it is revealed. I wrote a small shell script to loop sending password attempts to gpg. I found three words that caused this behavior in about two hours of trying. Two of the words worked on the file I initially posted and the other one on a different file in the contest. So, it seems rather common. Within a day or so, I could probably generate dozens of words that cause this behavior. Thanks again, Brad > Incidentally, these quick check bytes were used as the basis for an > ingenious attack against OpenPGP a few years ago. See > http://eprint.iacr.org/2005/033.pdf > > David From vedaal at nym.hush.com Mon Jul 30 16:45:19 2012 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 30 Jul 2012 10:45:19 -0400 Subject: Oracle behavior in Gnupg? // (was 'possible bug in gpg?') Message-ID: <20120730144519.A773314DBD8@smtp.hushmail.com> While playing around with --override-session key , have noticed that gpg gives many different sets of error messages when trying out different session keys. Here is an interesting example: First, the gnupg encrypted text: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (MingW32) Comment: encrypted to my default public key hQIMA1BvT6HTX7GGAQ/+KUw1RNONlmWW/RvNzAlZmS4cOUm7ioVnJc8kgtSgnBbS k952Lb6x5VaUyUbvXoNTeEdQGF1wJrDnV8Oz6VwqG/ZrlnUGOEFlGS9Mr2RZiktV eqG7jUFWnD9yyedbWqFJv9MND7QlAuZ1uikKPfATjrGWq+fkqb1bFAT0745BEaOL 7VQ988rUsjf7TrS0+NIIA5qjLZeS49vaUY/ZDqeVsaliweTkegBzhWftpMz4dDpE CxcAEZmEs4sleJq9BE0K/3A1U/1KDtzaYYRcsNFsIR6o3HhQyQ52zpmHwKY7WWc2 4ezMldyrcUGG7XSNGn2bkyIOfJmg7/1SJbpAjv6BjkH5G1IBY8R/ai4Lis58yeSr 6CbXDhQgowMRB1IH562SCSJyQIyu/GV+U5FBOOLkhWmqQjaNXP2LBgioMiyuBzsg gyY+rDHX4R4iql7oLflPPQVGZWjtAYw4Q96Iv2HzCZH7Q3H4LRONAk1woQjyT3as xKyxHNtqBhHfenTNep0ymeExYtcIsKYxLPj4WLRQ90rrOr1zY+N2eaWfDtIcEiAI Fgf20sHePnFm+EqwQQF3MrdhHFWdQzX+BuXDHJ+maRWWeXNNMjSAF3LjP2i027zT GglSUQOtRG7WGepM5sp2nNe+rfsCyHC3lIlujPHZ/LsdOi2IWeKKjOwUnfrp1LHS SAE9acMxZ2laREHDcIX2N5GdtdYp3EoS/1mMIeKEN+i2PuSaX8Xq6ToexVfpRvcs Mi6vGoldgMiOHN06g81oJdI4QYuQfudbEw== =x/RS -----END PGP MESSAGE----- here is the REAL session key: 10:A57B66F81B20273C587619AEA4C839D376DF50D23C946E97FB290D01CE 9E1F8D ----- Here is a 'starting' trial session key (chosen as a start as it's easy to describe and keep track of the changes) 10:123456789a123456789b123456789c123456789d123456789e123456789f1234 Here is the gpg output: gpg --override-session-key 10:123456789a123456789b123456 789c123456789d123456789e123456789f1234 e:\jt1.txt.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.12 (MingW32) gpg: armor header: Comment: encrypted to my default public key :pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186 data: [4094 bits] gpg: public key is D35FB186 gpg: public key encrypted data: good DEK :encrypted data packet: length: 72 mdc_method: 2 gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01- 22 "vedaal nistar (previous addresses were spam flooded) " gpg: TWOFISH encrypted data gpg: [don't know]: invalid packet (ctb=37) gpg: mdc_packet with invalid encoding gpg: decryption failed: invalid packet gpg: onepass_sig with unknown version 146 ----- Here is the session key with the REAL first 4 characters of the session key: 10:A57B56789a123456789b123456789c123456789d123456789e123456789f1234 Here is the gpg output: gpg --override-session-key 10:A57B56789a123456789b123456 789c123456789d123456789e123456789f1234 e:\jt1.txt.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.12 (MingW32) gpg: armor header: Comment: encrypted to my default public key :pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186 data: [4094 bits] gpg: public key is D35FB186 gpg: public key encrypted data: good DEK :encrypted data packet: length: 72 mdc_method: 2 gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01- 22 "vedaal nistar (previous addresses were spam flooded) " gpg: TWOFISH encrypted data :unknown packet: type 50, length 152 dump: 36 53 de 6e 59 4d d2 0f f4 09 98 87 31 bc a9 3c 1e fd 11 8a ae 92 5e 14 24: b8 d4 64 f5 be EOF gpg: mdc_packet with invalid encoding gpg: decryption failed: invalid packet ----- Have not tried all the 2^16 possiblities for the first 4 characters, but the few that I have tried lead to the same error message as the first trial. Could this be Oracle behavior on Gnupg's part, leading to a leak of the first 4 characters of the session key? fwiw, This doesn't extend to finding out the next 4 real characters of the session key. Here is the gpg output when the first 8 real characters are used: gpg --override-session-key 10:A57B66F89a123456789b123456 789c123456789d123456789e123456789f1234 e:\jt1.txt.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.12 (MingW32) gpg: armor header: Comment: encrypted to my default public key :pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186 data: [4094 bits] gpg: public key is D35FB186 gpg: public key encrypted data: good DEK :encrypted data packet: length: 72 mdc_method: 2 gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01- 22 "vedaal nistar (previous addresses were spam flooded) " gpg: TWOFISH encrypted data gpg: mdc_packet with invalid encoding gpg: decryption failed: invalid packet ---- Here is the gpg output when only the 2nd real 4 characters are used: gpg --override-session-key 10:123466F89a123456789b123456 789c123456789d123456789e123456789f1234 e:\jt1.txt.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.12 (MingW32) gpg: armor header: Comment: encrypted to my default public key :pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186 data: [4094 bits] gpg: public key is D35FB186 gpg: public key encrypted data: good DEK :encrypted data packet: length: 72 mdc_method: 2 gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01- 22 "vedaal nistar (previous addresses were spam flooded) " gpg: TWOFISH encrypted data gpg: [don't know]: invalid packet (ctb=32) gpg: mdc_packet with invalid encoding gpg: decryption failed: invalid packet Borh examples give error messages identical to the first one, except that when the first 8 real characters are used, the error message of 'gpg: [don't know]: invalid packet (ctb=37)' is not present, and when the second real 4 characters are used, there is a 'different' error message of 'gpg: [don't know]: invalid packet (ctb=32)'. Anything real about the 'oracle' action in any of this ? vedaal From dshaw at jabberwocky.com Mon Jul 30 17:14:11 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 30 Jul 2012 11:14:11 -0400 Subject: Oracle behavior in Gnupg? // (was 'possible bug in gpg?') In-Reply-To: <20120730144519.A773314DBD8@smtp.hushmail.com> References: <20120730144519.A773314DBD8@smtp.hushmail.com> Message-ID: <210AD4C7-C73F-47EE-B868-755DE860C4F1@jabberwocky.com> On Jul 30, 2012, at 10:45 AM, vedaal at nym.hush.com wrote: > While playing around with --override-session key , have noticed > that gpg gives many different sets of error messages when trying > out different session keys. [examples] > Borh examples give error messages identical to the first one, > except that when the first 8 real characters are used, the error > message of 'gpg: [don't know]: invalid packet (ctb=37)' is not > present, > and when the second real 4 characters are used, there is a > 'different' error message of 'gpg: [don't know]: invalid packet > (ctb=32)'. Yes, this is expected behavior. It follows from what I explained earlier in this thread. When you use --override-session-key, you bypass the quick check (after all, you gave the override key - what is there to check?) so you are seeing GnuPG choke on the invalid OpenPGP structures resulting from the garbage decryption. > Anything real about the 'oracle' action in any of this ? It's only an oracle if you return this output to the attacker, or in some other way allow the attacker to see differences (timing, for example) in the responses to what he submits to you. Don't do that ;) David From harningt at gmail.com Mon Jul 30 16:59:04 2012 From: harningt at gmail.com (Thomas Harning Jr.) Date: Mon, 30 Jul 2012 10:59:04 -0400 Subject: Oracle behavior in Gnupg? // (was 'possible bug in gpg?') In-Reply-To: <20120730144519.A773314DBD8@smtp.hushmail.com> References: <20120730144519.A773314DBD8@smtp.hushmail.com> Message-ID: On Mon, Jul 30, 2012 at 10:45 AM, wrote: > While playing around with --override-session key , have noticed > that gpg gives many different sets of error messages when trying > out different session keys. > ... CUT ... > Borh examples give error messages identical to the first one, > except that when the first 8 real characters are used, the error > message of 'gpg: [don't know]: invalid packet (ctb=37)' is not > present, > and when the second real 4 characters are used, there is a > 'different' error message of 'gpg: [don't know]: invalid packet > (ctb=32)'. > > Anything real about the 'oracle' action in any of this ? > > > vedaal Should we be worried about "oracle" behavior on a local running application? It seems "oracle" behavior is all the rage even though it makes ZERO sense on a local machine unless there is obfuscation involved. On a local machine, you could take the data and just run the algorithms yourself. Does anyone run gpg on a server and let people send arbitrary data to it? If so, then I'd suggest that a "quiet" execution be performed that way only the exit code can be used that it's failure. -- Thomas Harning Jr. (http://about.me/harningt) Please support my wife as she runs her first marathon to raise $2,620 for St Jude Children's Hospital - http://heroes.stjude.org/jenniferharning From dvd-paula18 at att.net Mon Jul 30 13:21:43 2012 From: dvd-paula18 at att.net (David Paul) Date: Mon, 30 Jul 2012 12:21:43 +0100 Subject: Urgent Message-ID: <984117.28915.bm@smtp215.mail.gq1.yahoo.com> Attn: Please and a good day to you. I have an important information for the owner of this email but first of all, I do not know if I am talking to the right person, I will like you to confirm if you are the owner of this email ID. By your respond, I will proceed to let you know what news I have for you. I am taking this measure in other not to make any mistake because of the sensitivity of the information I have for you. Awaiting Your Responds David Paul. From brad at 16systems.com Mon Jul 30 15:45:29 2012 From: brad at 16systems.com (Brad Tilley) Date: Mon, 30 Jul 2012 09:45:29 -0400 (EDT) Subject: Possible bug in gpg? In-Reply-To: <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> Message-ID: <57255.128.173.192.90.1343655929.squirrel@webmail.tuffmail.net> Thanks for the reply David. The file was actually cracked so we'll know the plaintext sometime soon, although that may likely matter not. > However, people being people, they can easily typo the passphrase, and > given the method above, if the passphrase is wrong, the session key will > be wrong, and the data decrypted will be gibberish. To combat this, > OpenPGP has two "quick check" bytes in the encrypted data packet. > Basically, they're a repetition of two random bytes from earlier in the > message. The idea is that if the session key is wrong (i.e. the > passphrase is wrong), the original random bytes won't match their > repetition, and the client can immediately say "Wrong passphrase!" rather > than blithely continue and potentially decrypt lots of data that won't > turn out to be valid. That seems like a reasonable check to make in most cases. I know that symmetric-key algorithms will happily output garbage when the wrong password is used and that may confuse some people, but then again, some others may actually prefer that. If I was expecting a pdf file (upon successful decryption) and there was no pdf header up front (only randomish looking bytes all through the file), then that would be a decent indication, to me, that the bytes I saw were not actually decrypted. > The practical upshot of this design is that while it works most of the > time (in that virtually all incorrect passwords will be immediately > flagged as such), each symmetrically encrypted message has the chance for > other, incorrect, passphrases that nevertheless will pass the quick check. > Obviously, these cannot decrypt the message, but they mangle into > (invalid) session keys that just so happen to decrypt the data so that the > 16-bit quick check matches, allowing the client to proceed, and decrypt > (incorrectly) the rest of the data. Usually this fails fairly quickly > afterwards as the data decrypted is not valid OpenPGP structures, so the > client will stop with an error message about being unable to read the > file. > > In this particular case, the !=X passphrase passes the quick check, and > the incorrectly decrypted data happens to look like a packet of packet > type 0, of length 942141745. GPG ignores the invalid packet (there is no > packet type 0), and so no output is generated. > > So, assuming my guess is right, it's not a bug in OpenPGP or GnuPG (though > perhaps giving an error when it saw the packet type of 0 would have been > better), but a pretty unlikely confluence of events. How did you come up > with the !=X passphrase? Exhaustive search? I'd be curious to find out > what the real password is, once it is revealed. I wrote a small shell script to loop sending password attempts to gpg. I found three words that caused this behavior in about two hours of trying. Two of the words worked on the file I initially posted and the other one on a different file in the contest. So, it seems rather common. Within a day or so, I could probably generate dozens of words that cause this behavior. Thanks again, Brad > Incidentally, these quick check bytes were used as the basis for an > ingenious attack against OpenPGP a few years ago. See > http://eprint.iacr.org/2005/033.pdf > > David From neyara-lidia at bol.com.br Mon Jul 30 12:01:21 2012 From: neyara-lidia at bol.com.br (neyara-lidia) Date: Mon, 30 Jul 2012 07:01:21 -0300 Subject: LIMPE SEU CPF/SPC/SERASA Message-ID: <50165b71e9e81_457e869ac78976@a4-winter17.tmail> An HTML attachment was scrubbed... URL: From peter.segment at wronghead.com Mon Jul 30 14:51:16 2012 From: peter.segment at wronghead.com (peter.segment at wronghead.com) Date: Mon, 30 Jul 2012 12:51:16 +0000 Subject: gpg "simplified"? Message-ID: <50168344.9090000@dfgh.net> I have been asked to help a small group of individuals (perhaps hundreds, not thousands) with secure data exchange (including, but not restricted to e-mail). Use of full gpg is way beyond their capabilities. I am wondering if anybody has heard of a simplified version of gpg; or failing that, I would like to hear any comments on the feasibility of a collaborative project to create such a variant, as I am convinced there would have to be a wider applicability of it. The following describes the requirements: 1) The program is CLI and operates on (i.e., it encrypts and decrypts) binary files. It has no connection with any mail client program or server or mail service and provides no key management functionality whatsoever. 2) Once encrypted with a (single!) recipients public key, the file consists of bytes indistinguishable from a random stream. 3) The program can be run from removable media, i.e., it requires no installation and assumes no network access for either key exchange or in operation. There are binaries for all three major platforms (Win32, Linux and Mac OSX). 4) Single key, public or private, resides in a single file. This file is encrypted with operator's public key and consists of bytes indistinguishable from a random byte stream. 5) Public key includes a textual description, but no unique identification other than the hash of the key. TIA, Peter M. From Contact at rule61.info Fri Jul 20 10:39:29 2012 From: Contact at rule61.info (=?iso-8859-15?Q?Croisi=E8re_fluviale?=) Date: Fri, 20 Jul 2012 10:39:29 +0200 Subject: Promos vacances : enfin des vacances originales Message-ID: <8lp76EPoVdbcVRbJSgIsmcm1NFqeaaYF0znN0mrHakkh@rule61.info> Untitled Document Vous pilotez un bateau totalement équipé (four, réfrigérateur, feux de cuisson, cabines confortables) vous permettant d'étre autonome presque comme à la maison. Navigation sans permis et sans expérience, de 2 à 12 personnes... >> Lire la suite * Prix par personne, sur la base de 2 personnes minimum à bord, en flotte budget, forfait horaire de navigation (carburant) inclus ; hors assurances facultatives et extras Patrimoine, gastronomie, vélo, pêche, détente, pas le temps de s'ennuyer en croisière fluviale ! Découvrez le concept de bateau habitable >> ici Promos lastminute au départ de plusieurs régions >> ici Un devis ? des conseils ?On vous appelle - >> ici Le "best seller" : le tarpon 42 Quattro prestige >> Lire la suite __________________________________________________ France Passion Plaisance / Les Canalous - BP 89 - 71602 Paray-le-Monial Cedex - France Tél : 03 85 53 76 70 (appel non surtaxé) - contact at france-passion-plaisance.fr Retrouvez notre brochure sur : France-passion-plaisance.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pacific2231D at poem.ocn.ne.jp Mon Jul 30 18:59:30 2012 From: Pacific2231D at poem.ocn.ne.jp (Pacific Island) Date: Mon, 30 Jul 2012 22:29:30 +0530 Subject: PLEASE ACCEPT THIS COMPENSATION AND FORGIVE ME. Message-ID: <20120730165930.3F0413643C5@mv-osn-hcb007.ocn.ad.jp> An HTML attachment was scrubbed... URL: From brad at 16systems.com Mon Jul 30 20:32:15 2012 From: brad at 16systems.com (Brad Tilley) Date: Mon, 30 Jul 2012 14:32:15 -0400 (EDT) Subject: Possible bug in gpg? In-Reply-To: <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> References: <57168.108.4.178.254.1343499499.squirrel@webmail.tuffmail.net> <0F1AFD96-5A50-49AE-99FF-22912193FE3D@jabberwocky.com> Message-ID: <57579.128.173.192.90.1343673135.squirrel@webmail.tuffmail.net> > I'd be curious to find out what the real password is, once it is revealed. The actual password is glucose. Brad From ciprian.craciun at gmail.com Mon Jul 30 21:15:55 2012 From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun) Date: Mon, 30 Jul 2012 22:15:55 +0300 Subject: pipe passphrase to unlock key In-Reply-To: References: Message-ID: On Wed, Jun 27, 2012 at 8:42 PM, Face wrote: > Hell all, > > I am trying to pipe my passphrase to unlock the key. my problem is > like this, when I use git > to sign a tag gnupg ask for the passphrase and i need to pipe the passphrase. > > I try > echo "my long passphrase" | git tag -s 1.0.0.42 -m 'version 1.0.0.1' > > however it did not work. > > > is there is any workaround for my problem ? > > > Any help would be much appreciated. > > Sincerely, > falazemi > > note: using pinentry-curses Hope my feedback is not too late... But either way I don't think it would help too much as neither solution is straight-forward... So the only workaround -- that I know of, but I'm not a GnuPG developer -- is to either: * implement your own "fake" `gpg-agent` which I have no ideea what actually implies; * implement your own "fake" `pinentry` which would be much simpler as it only has to implement the assuan protocol; but you'll have to start a separate instance of `gpg-agent` just for this situation, which unfortunately will background and you'll have to "hunt it down" once your done, or you could use that to start your command as a child of `gpg-agent` which is a horrible hack; * (preferably) implement a fake `gpg` which does the following: opens a pipe as you have done in your example, writes the password and then calls the real `gpg` with an additional argument `--passphrase-fd`; (this works only as long as Git uses the `gpg` tool and not the library... fortunately this is true today and I guess it's unlikely to change...) Related to this last option, and assuming you are on Linux and are using a recent BASH version (mine is 4.x), you could do what you want as bellow (code not tested): ~~~~ password=... env \ GPG_PASSPHRASE_FD=<( printf -- "${password}" ) \ PATH="a-folder-where-your-gpg-wrapper-is:${PATH}" \ git ... ~~~~ Notes: * the syntax <( ... ) replaces the token with the path of a pipe ready to read from the sub-command in the parenthesis; (see the Bash manual); * as you can't send arguments to `gpg` via Git you use environment variables; * the password is not visible in the environment of the `git` or its children, but could be read from that descriptor; * depending on Bash it could actually be stored on the file system thus maybe leaked to permanent storage... Where your `gpg` wrapper would be (not tested but adapted from another script of mine): ~~~~ #!/bin/bash # see Bash manual for the magic in the following line... :) set -e -E -u -o pipefail || exit 1 _self_path="$( readlink -e "${0}" )" _self_name="$( basename "${0}" )" # this would contain each resolved file in the path # if we are a wrapper then the first is the wrapper # and the second must be the real one _paths="$( which -a -- "${_self_name}" )" _next= while read _path do _path="$( readlink -e "${_path}" )" test "${_path}" != "${_self_path}" || continue _next="${_path}" break done <<<"${_paths}" # it will silently fail if we haven't found the real gpg test -n "${_next}" # we assume that someone has exported the `GPG_PASSPHRASE_FD` # and that there we have a path to a pipe to read from # we also assume that we have at least another argument exec "${_next}" --passphrase-fd "${GPG_PASSPHRASE_FD}" "${@}" exit 1 ~~~~ Hope this helps you (one moth later) although it is a crude hack... :( But the real problems is still open and should be solved by extending both Git and GnuPG... Ciprian. P.S.: If you don't like the Bash script I have an neat idea on how to simply implement it in C, in a similar fashion, which would guarantee you zero file system exposure. From yyy at yyy.id.lv Tue Jul 31 07:11:00 2012 From: yyy at yyy.id.lv (yyy) Date: Tue, 31 Jul 2012 08:11:00 +0300 Subject: gpg "simplified"? In-Reply-To: <50168344.9090000@dfgh.net> References: <50168344.9090000@dfgh.net> Message-ID: <501768E4.8010603@yyy.id.lv> On 2012.07.30. 15:51, peter.segment at wronghead.com wrote: > I have been asked to help a small group of individuals > (perhaps hundreds, not thousands) with secure data exchange > (including, but not restricted to e-mail). > > Use of full gpg is way beyond their capabilities. I am > wondering if anybody has heard of a simplified version > of gpg; or failing that, I would like to hear any comments > on the feasibility of a collaborative project to create > such a variant, as I am convinced there would have to be > a wider applicability of it. > > The following describes the requirements: > > 1) The program is CLI and operates on (i.e., it encrypts and > decrypts) binary files. It has no connection with any mail > client program or server or mail service and provides > no key management functionality whatsoever. gpg is a CLI program which encrypts and decrypts binary files, by default it has no connection with any mail server or service openssl smime tool does the same, and unlike gpg, has no key management functionality (for encryption and decryption only) (it does have size limits, it needs as much memory, as size of file to be encrypted or decrypted) > 2) Once encrypted with a (single!) recipients public key, the > file consists of bytes indistinguishable from a random stream. this probably will not be possible with standard openpgp (or smime) > 3) The program can be run from removable media, i.e., it > requires no installation and assumes no network access for > either key exchange or in operation. There are binaries > for all three major platforms (Win32, Linux and Mac OSX). I have heard, that gpg 1.4 supports such operation, but have not tested it myself. gpg2 certainly will not work. openssl some times works, some times not. (I have tested only on windows, there have been some dependencies on system dlls). > 4) Single key, public or private, resides in a single > file. This file is encrypted with operator's public key > and consists of bytes indistinguishable from a random byte > stream. this probably will not be possible with standard openpgp (or smime) if private key is encrypted with it's public key, it becomes inaccessible, because unencrypted private key is needed to decrypt it. > 5) Public key includes a textual description, but no > unique identification other than the hash of the key. > gpg keys can be generated this way, x509 certs also can be generated this way. From wk at gnupg.org Tue Jul 31 11:24:27 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 11:24:27 +0200 Subject: Oracle behavior in Gnupg? // In-Reply-To: (Thomas Harning, Jr.'s message of "Mon, 30 Jul 2012 10:59:04 -0400") References: <20120730144519.A773314DBD8@smtp.hushmail.com> Message-ID: <87mx2g706s.fsf@vigenere.g10code.de> On Mon, 30 Jul 2012 16:59, harningt at gmail.com said: > it? If so, then I'd suggest that a "quiet" execution be performed that > way only the exit code can be used that it's failure. You should not rely on the exit code but parse all the information returned by GPG. GPGME makes this easy. Given that GPG is just a tool and not a complete automated cryptographic system, the developer needs to care about certain attacks by himself. There are several points to watch out for, not only oracle attacks, but for example also replay attacks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 31 11:35:00 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 11:35:00 +0200 Subject: gpg "simplified"? In-Reply-To: <501768E4.8010603@yyy.id.lv> (yyy@yyy.id.lv's message of "Tue, 31 Jul 2012 08:11:00 +0300") References: <50168344.9090000@dfgh.net> <501768E4.8010603@yyy.id.lv> Message-ID: <87ehns6zp7.fsf@vigenere.g10code.de> On Tue, 31 Jul 2012 07:11, yyy at yyy.id.lv said: >> 3) The program can be run from removable media, i.e., it >> requires no installation and assumes no network access for >> either key exchange or in operation. There are binaries >> for all three major platforms (Win32, Linux and Mac OSX). > I have heard, that gpg 1.4 supports such operation, but > have not tested it myself. gpg2 certainly will not work. Why do you think gpg2 won't work or does any network access without user consent? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 31 11:32:37 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 11:32:37 +0200 Subject: pipe passphrase to unlock key In-Reply-To: (Ciprian Dorin Craciun's message of "Mon, 30 Jul 2012 22:15:55 +0300") References: Message-ID: <87ipd46zt6.fsf@vigenere.g10code.de> On Mon, 30 Jul 2012 21:15, ciprian.craciun at gmail.com said: > * implement your own "fake" `gpg-agent` which I have no ideea what > actually implies; Don't do this. > * implement your own "fake" `pinentry` which would be much simpler > as it only has to implement the assuan protocol; but you'll have to > start a separate instance of `gpg-agent` just for this situation, I would not call this a ?fake? Pinentry. Actually GnuPG has support to switch the pinentry on demand: @item PINENTRY_USER_DATA This value is passed via gpg-agent to pinentry. It is useful to convey extra information to a custom pinentry. Your application may set this environment variable to tell a pinentry wrapper to divert to a custom one. > * (preferably) implement a fake `gpg` which does the following: > opens a pipe as you have done in your example, writes the password and Not a good idea, because GnuPG 2.1 requires the gpg-agent and won't see any private key stuff. > password=... > > env \ > GPG_PASSPHRASE_FD=<( printf -- "${password}" ) \ > PATH="a-folder-where-your-gpg-wrapper-is:${PATH}" \ > git ... This is a bad advise. If you store the passphrase in a file, you are usually better off not to use a passphrase at all. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ben at adversary.org Tue Jul 31 11:56:00 2012 From: ben at adversary.org (Ben McGinnes) Date: Tue, 31 Jul 2012 19:56:00 +1000 Subject: Oracle behavior in Gnupg? // (was 'possible bug in gpg?') In-Reply-To: <210AD4C7-C73F-47EE-B868-755DE860C4F1@jabberwocky.com> References: <20120730144519.A773314DBD8@smtp.hushmail.com> <210AD4C7-C73F-47EE-B868-755DE860C4F1@jabberwocky.com> Message-ID: <5017ABB0.8020601@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 31/07/12 1:14 AM, David Shaw wrote: > > Yes, this is expected behavior. It follows from what I explained > earlier in this thread. When you use --override-session-key, you > bypass the quick check (after all, you gave the override key - > what is there to check?) so you are seeing GnuPG choke on the > invalid OpenPGP structures resulting from the garbage decryption. On a related note, is it possible to extract the session key (--show-session-key), but without decrypting the file in the process? Just obtain the session key and stop there? I've already tried -n (--dry-run) and that still decrypts the file. Regards, Ben -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJQF6uvAAoJEH/y03E1x1U8yrkL/1M6WOjwhLQ28iD5Bg+Ensu0 oezAbRumzdCe9l2H0seZ7NG79+/mLwlzIuVXe2IN10my2daesLfzHGyWNsj9bM/x BNOpM+daBLd+lb9ceTsDayTbcYkpHbkhNW99UR50N5fNJWEeNwk6ukjk0c3QIXhk HyoQG+OCzNc4W48mCWwt5tz3IObdjvzlpn/rll9n7i55BQIlwCd5TqfoWU8eSkFW xzvT50P9rhZ0SaY7FVH1J6TYUKh7dN4IDv2jOUPghtGKkBh36bwQmfOSjmuwxm2w SGx7eCKGoRx1M3JrkZKzwepl5VZtDhiERI9e3v1uz0tYsdBaBNzobkfu+am1PiD4 oMh1ic7OazieqCcfNYJyi5pBAIXq1oc71YyVzlNVlndmHAgu13o6eymijwb8EQqg x1YcDG9RYCay4gJ5tzURahwpBRAz85znQDjjD20GA/Ocdgez5qDgLCeVScy/1+RG xnPiNzPyEOjR73yDtIWPfgoHKtsuH+WjHuCVIs1BSQ== =CxOe -----END PGP SIGNATURE----- From olav at enigmail.net Tue Jul 31 12:00:23 2012 From: olav at enigmail.net (Olav Seyfarth) Date: Tue, 31 Jul 2012 12:00:23 +0200 Subject: Mac OS X 10.8 and OpenPGP Cards In-Reply-To: <20120726193445.GA1612@clarus.mgh.harvard.edu> References: <20120726193445.GA1612@clarus.mgh.harvard.edu> Message-ID: <5017ACB7.5030908@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi Kevin, list, > I just upgraded from Mac OS X 10.7 to 10.8, and my ZeitControl cards, which > were formerly working perfectly, are now inaccessible. please note that 10.8 brings significant changes (namely sandboxing) to Mac OS X which does have impact on most software. Luke Le from GPGtools posted on 26.07.: > I Mountain Lion Mail.app is running in a sandbox which has a deep impact > on GPGMail: it can no longer communicate with gpg using a sub process. http://support.gpgtools.org/discussions/everything/1573-os-x-108-mountain-lion-compatibility/ Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Dies ist eine elektronische Signatur - http://enigmail.mozdev.org/ iQGcBAEBAwAGBQJQF6y1AAoJEKGX32tq4e9WUbIL/A0rxQt2i2KDayZN4WkF16Fr b4oKp07nz7hI5HTXCTvly8/7QNtgE4ZSgUezz94Oo2gZsVo/OhCbQeIdYY1vvCEx VTuy5EdUlvxRUVGoSPEL1RAZh+3AR4xKxNgtO39wW+XNas+3MhiUnhogsk/T+T6T 15oY5ZtjN737JvcLlWUgbqJs8U10oYyW0lQkuPAn7f4tElQc4LTGYyWwXstKKcaa SNI8NLwcBqy57FItfGAOLTjtQ+qDF1DmaA9acj9cFniCv55q4xzH/6jkeS15w5BT FjcYFVcuF8eJvyt0iL66jSAoL69nz5S4NCHBWpo8c9DIw15qc0EgH5Y/KLqW+MHL kBD+9HfrrUrvwKe9kb6uPlfcjdJClKgL8e1IgBY5rki+0yzEqLnrjFV9aSR71mw/ UHYyNgVz/mgFf0hnhni8uPsrO5aoUn4W2VP/dylHFT2m4FeRHMVyUNfyHHQYwT5n ByBd2JGNjy6VDBDTi9qXa9VpYNkZg3a2KxYDKRBFYQ== =kSkv -----END PGP SIGNATURE----- From wk at gnupg.org Tue Jul 31 13:53:42 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 13:53:42 +0200 Subject: Oracle behavior in Gnupg? // In-Reply-To: <5017ABB0.8020601@adversary.org> (Ben McGinnes's message of "Tue, 31 Jul 2012 19:56:00 +1000") References: <20120730144519.A773314DBD8@smtp.hushmail.com> <210AD4C7-C73F-47EE-B868-755DE860C4F1@jabberwocky.com> <5017ABB0.8020601@adversary.org> Message-ID: <87txwo5epl.fsf@vigenere.g10code.de> On Tue, 31 Jul 2012 11:56, ben at adversary.org said: > On a related note, is it possible to extract the session key > (--show-session-key), but without decrypting the file in the process? > Just obtain the session key and stop there? I've already tried -n There is no such option. I once did something similar, maybe you can make use of attached patch. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-1.4.4-freenigma-2.diff Type: text/x-diff Size: 9787 bytes Desc: not available URL: From ciprian.craciun at gmail.com Tue Jul 31 12:54:08 2012 From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun) Date: Tue, 31 Jul 2012 13:54:08 +0300 Subject: pipe passphrase to unlock key In-Reply-To: <87ipd46zt6.fsf@vigenere.g10code.de> References: <87ipd46zt6.fsf@vigenere.g10code.de> Message-ID: On Tue, Jul 31, 2012 at 12:32 PM, Werner Koch wrote: > On Mon, 30 Jul 2012 21:15, ciprian.craciun at gmail.com said: >> * (preferably) implement a fake `gpg` which does the following: >> opens a pipe as you have done in your example, writes the password and > > Not a good idea, because GnuPG 2.1 requires the gpg-agent and won't see > any private key stuff. Not necessarily if you use the `--batch`, `--no-use-agent`, or `--no-tty` (or a mix of the I'm not sure right now, but the manual is.) >> password=... >> >> env \ >> GPG_PASSPHRASE_FD=<( printf -- "${password}" ) \ >> PATH="a-folder-where-your-gpg-wrapper-is:${PATH}" \ >> git ... > > This is a bad advise. If you store the passphrase in a file, you are > usually better off not to use a passphrase at all. I completely agree with you on this. But the above didn't imply saving the password in the script... `password=...` was just a suggestion that you need to somehow obtain the password, and then use it with the Bash `<( ... )` feature. (Although I've suggested it might bee leaked to the file system.) But on the other side, not always you have the option of running a `gpg-agent` (for example on server side of a background job, etc.), thus I guess this method has its uses. Although I once more agree with you that if you need to automate password handling maybe it's better not to use it. The only exception I could think of is if you hold the password entirely into memory of a daemon process that delegates signatures, but you feed it manually at boot-up, this way at least if someone steals your device it will have a harder time getting your actual key. (I completely ignore the "warm" boot attacks, root-kits or the like... As in these cases your done fore regardless...) To complete my response, this is what I've replied privately to the original poster, about the solution not involving Bash. Ciprian. ~~~~~~~~~~~~~~~~ [How to give the password to `gpg` while not controlling its invocation.] The solution is quite simple and I think it is also portable. But it still uses the customized `gpg` wrapper, it only solves the potential password leaking to the file system. I'll just highlight the solution, the details being quite simple: * use the `pipe2` syscall (and use the `O_NONBLOCK` flag just to be sure); * write the password to the pipe, then close the write end; (the read end is still open;) * (maybe be sure that the descriptor value is above or equal to 3;) * export an environment variable holding the file descriptor value; * `exec` your `git` process which will inherit the open end of the pipe; * (in turn your `gpg` wrapper will inherit the descriptor and the environment variable;) What it gains you: * first of all the password is now stored only inside the pipe and can't be recovered from the arguments or environment of the processes (via `/proc/$pid/cmdline` or `.../environ`); * the password can be read exactly once by at most one process (see below for the caveat); * you have no other extra process running (as would happen in the `<( ... )` Bash solution); * if `gpg` would have accepted a `GPG_PASSPHRASE_FD` environment variable you wouldn't have needed a wrapper script for `gpg`; (this works for some other programs;) What it doesn't grant: * complete password secrecy, as anyone with proper rights (usually any of your processes) could still quickly open `/proc/$pid/fd/$num` and read the password; If you need the password multiple times, this still can still be done but you'll have to complicate the wrapper too, by: * exporting both the read and write ends; * the wrapper executes exactly one `read` operation, it writes it again to the write end; (it doesn't close either ends;) * it then creates another pipe and applies the trick as initially described which is passed to `gpg`; * (this works because POSIX mandates that a write less than a page (4kb on Linux) must match exactly a read operation, thus maintaining data boundry;) From Lists.gnupg at mephisto.fastmail.net Tue Jul 31 14:44:31 2012 From: Lists.gnupg at mephisto.fastmail.net (Kevin Kammer) Date: Tue, 31 Jul 2012 08:44:31 -0400 Subject: Mac OS X 10.8 and OpenPGP Cards In-Reply-To: <5017ACB7.5030908@enigmail.net> References: <20120726193445.GA1612@clarus.mgh.harvard.edu> <5017ACB7.5030908@enigmail.net> Message-ID: <20120731124430.GA310@clarus.mgh.harvard.edu> On Tue, Jul 31, 2012 at 12:00:23PM +0200 Also sprach Olav Seyfarth: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Hi Kevin, list, > > > I just upgraded from Mac OS X 10.7 to 10.8, and my ZeitControl cards, which > > were formerly working perfectly, are now inaccessible. > > please note that 10.8 brings significant changes (namely sandboxing) to Mac OS X > which does have impact on most software. Luke Le from GPGtools posted on 26.07.: > > > I Mountain Lion Mail.app is running in a sandbox which has a deep impact > > on GPGMail: it can no longer communicate with gpg using a sub process. > > http://support.gpgtools.org/discussions/everything/1573-os-x-108-mountain-lion-compatibility/ > Application sandboxing is now mandatory only for applications installed through the Mac App Store; applications installed by the root user (or equivalent) outside of Apple's "official" channels still have free reign over the whole system, as they always did. While the information and link quoted above will almost certainly be helpful for some people with Apple Mail/GPGTools problems, there is definitely more going on in my case. For one thing, the problems I have observed with GnuPG 2.x are present outside of any mail agent, or other application calling gpg2 (i.e. gpg2 --card-status does not work from the command line--no mail involved). Aside from that, I typically sign/encrypt messages from Mutt, not Apple Mail, so the sandbox is unlikely to effect me in the near future anyway. Since I have discovered that GnuPG 1 is mostly usable with my cards at this point, I will try to soldier on with that, but it's annoying that GnuPG 2, which was working fine previously, is suddenly such a mess due to this update. From wk at gnupg.org Tue Jul 31 17:35:09 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 17:35:09 +0200 Subject: pipe passphrase to unlock key In-Reply-To: (Ciprian Dorin Craciun's message of "Tue, 31 Jul 2012 13:54:08 +0300") References: <87ipd46zt6.fsf@vigenere.g10code.de> Message-ID: <87629454gi.fsf@vigenere.g10code.de> On Tue, 31 Jul 2012 12:54, ciprian.craciun at gmail.com said: >> Not a good idea, because GnuPG 2.1 requires the gpg-agent and won't see >> any private key stuff. > > Not necessarily if you use the `--batch`, `--no-use-agent`, or > `--no-tty` (or a mix of the I'm not sure right now, but the manual Nope. Recall that I implemented the stuff. > But on the other side, not always you have the option of running a > `gpg-agent` (for example on server side of a background job, etc.), I run it on servers ;-). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yyy at yyy.id.lv Tue Jul 31 17:40:01 2012 From: yyy at yyy.id.lv (yyy) Date: Tue, 31 Jul 2012 18:40:01 +0300 Subject: gpg "simplified"? In-Reply-To: <87ehns6zp7.fsf@vigenere.g10code.de> References: <50168344.9090000@dfgh.net> <501768E4.8010603@yyy.id.lv> <87ehns6zp7.fsf@vigenere.g10code.de> Message-ID: <5017FC51.3010602@yyy.id.lv> On 2012.07.31. 12:35, Werner Koch wrote: > On Tue, 31 Jul 2012 07:11, yyy at yyy.id.lv said: > > Why do you think gpg2 won't work or does any network access without user > consent? > gpg2 requires gpg agent..., i was referring to posibility to making it a portable application (not requiring installation, not leaving traces in host computer when run) there (in this list) have been some threads about how to get rid of gpg agent in gpg2, so it would behave more like gpg 1.4, but answer has been, that it is not possible. No application considered requires any network access (gpg1.4, gpg2, openssl) From ciprian.craciun at gmail.com Tue Jul 31 17:53:50 2012 From: ciprian.craciun at gmail.com (Ciprian Dorin Craciun) Date: Tue, 31 Jul 2012 18:53:50 +0300 Subject: pipe passphrase to unlock key In-Reply-To: <87629454gi.fsf@vigenere.g10code.de> References: <87ipd46zt6.fsf@vigenere.g10code.de> <87629454gi.fsf@vigenere.g10code.de> Message-ID: On Tue, Jul 31, 2012 at 6:35 PM, Werner Koch wrote: > On Tue, 31 Jul 2012 12:54, ciprian.craciun at gmail.com said: > >>> Not a good idea, because GnuPG 2.1 requires the gpg-agent and won't see >>> any private key stuff. >> >> Not necessarily if you use the `--batch`, `--no-use-agent`, or >> `--no-tty` (or a mix of the I'm not sure right now, but the manual > > Nope. Recall that I implemented the stuff. (Sorry I didn't knew you've implemented it.) :) Mmm... Didn't read the "fine print" of the manual... (Which isn't that fine print...) ~~~~ --no-use-agent This is dummy option. gpg2 always requires the agent. ~~~~ Then I'm a little bit at unease... First of all I would really have liked the tool to not just ignore the `--no-user-agent` flag and bail out... Then if I use the `--batch` option it doesn't ask for a password, thus what is the purpose of the agent anymore? (Except handling cards which isn't the case in most instances...) >> But on the other side, not always you have the option of running a >> `gpg-agent` (for example on server side of a background job, etc.), > > I run it on servers ;-). I bet you can run it on servers. And I bet it works nicely. What I also bet is that it leaves dangling "background" processes lying, because -- if I'm correct -- the following happens: * if I implement a service that isn't started with an `gpg-agent` properly set up, then * each invocation of `gpg2` will start its own, but not as a child, but by making it double fork in the background; * but unfortunately the tool won't be able to export that environment variables to its parent... * and also after the invocation the agent would just remain there; Maybe the tool would check if someone listens on the socket and not restart another agent, but still we have at least one agent running, and for no purpose as there is no password to enter... Or? Ciprian. P.S.: Maybe you remember that I've sent a patch in the past that adds an option to the agent not to double fork (which was rejected)... I really still strongly believe that double forking is very bad, and should be done only in exceptional cases... (And the GnuPG or SSH agents aren't one of those cases...) From auto15963931 at hushmail.com Tue Jul 31 18:57:17 2012 From: auto15963931 at hushmail.com (auto15963931) Date: Tue, 31 Jul 2012 11:57:17 -0500 Subject: message signature types Message-ID: If this is the wrong place to ask, please point me in the right direction. Where can I learn more about importing, if such a thing is even done this way, and making use of message signatures which utilize an "smime.p7s" file? I got a message from someone who uses this, and I need to learn about verifying and downloading from a keyserver files like this. Especially important for me is learning how to check whether it had been revoked, etc. Where is a support group for this sort of signature if this is not it? Thanks. From wk at gnupg.org Tue Jul 31 20:54:44 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 20:54:44 +0200 Subject: pipe passphrase to unlock key In-Reply-To: (Ciprian Dorin Craciun's message of "Tue, 31 Jul 2012 18:53:50 +0300") References: <87ipd46zt6.fsf@vigenere.g10code.de> <87629454gi.fsf@vigenere.g10code.de> Message-ID: <87vch34v7v.fsf@vigenere.g10code.de> On Tue, 31 Jul 2012 17:53, ciprian.craciun at gmail.com said: > First of all I would really have liked the tool to not just ignore > the `--no-user-agent` flag and bail out... That would make migration for user of 2.0 to 2.1 too complicate. We try to do the migration as smooth as possible. > thus what is the purpose of the agent anymore? (Except handling cards > which isn't the case in most instances...) The agent does not handle cards. It just acts as a proxy for scdaemon. What the agent does is to perform all operations involving the private key (e.g. signing and decryption of the session key). GPGSM works this way for 10 years now; 2.1 completes it and moved the private key operations for OpenPGP also to the agent. > * each invocation of `gpg2` will start its own, but not as a > child, but by making it double fork in the background; That was the default in 2.0 on Unix. 2.1 will start the agent only once and keep it around. The Windows version of 2.0 does this for a few years now. > * but unfortunately the tool won't be able to export that > environment variables to its parent... No problem anymore. We need an envvar only for the ssh support and that is a fixed value. > * and also after the invocation the agent would just remain there; Right. > not restart another agent, but still we have at least one agent > running, and for no purpose as there is no password to enter... The agent is not for the passphrase. The passphrase handling code is only a minor function block. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jul 31 20:58:37 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jul 2012 20:58:37 +0200 Subject: message signature types In-Reply-To: (auto's message of "Tue, 31 Jul 2012 11:57:17 -0500") References: Message-ID: <87r4rr4v1e.fsf@vigenere.g10code.de> On Tue, 31 Jul 2012 18:57, auto15963931 at hushmail.com said: > even done this way, and making use of message signatures which utilize > an "smime.p7s" file? I got a message from someone who uses this, and I Feel free to ask here. GnuPG has a complete CMS/X.509 (aka S/MIME) implementation. > like this. Especially important for me is learning how to check whether > it had been revoked, etc. Where is a support group for this sort of By default GPGSM consults a CRL - in theory this is all you need. The little remaining problem is that PKIX (the public key infrastructure used with S/MIME) does not work at all at a global level - or well, it is not as secure as Verislime, Diginotar, and others try to tell you. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter.segment at wronghead.com Tue Jul 31 14:17:48 2012 From: peter.segment at wronghead.com (peter.segment at wronghead.com) Date: Tue, 31 Jul 2012 12:17:48 +0000 Subject: gpg "simplified"? In-Reply-To: <87ehns6zp7.fsf@vigenere.g10code.de> References: <50168344.9090000@dfgh.net> <501768E4.8010603@yyy.id.lv> <87ehns6zp7.fsf@vigenere.g10code.de> Message-ID: <5017CCEC.5010103@dfgh.net> On 31/07/12 09:35, Werner Koch - wk at gnupg.org wrote: > Why do you think gpg2 won't work or does any network access > without user consent? Correct me if I'm wrong, but it is unreasonable to expect anybody to successfully and safely use gpg without understanding the concepts and mastering the skills essential to the WOT: key signing, sub-keys, revocations etc. This makes the use of gpg (or even an early, "portable" pgp version (2.6.something IIRC?) unfeasible). As far as the network access is concerned, the best (the only?) way to ensure there is no compromising network access is to have a network-ignorant application program. In this application I have a group of otherwise technically competent users that, however, have no need or interest to securely communicate or exchange data with anyone who is not a group member and has not been introduced to them by the group manager. (Please take the term "group manager" in the widest possible sense). He can easily do all the necessary key management (distribution, verification, revocation...) functions in the course of his other (quite extensive, actually) group management tasks and activities. Most users in this group have no single computer they operate on. Occasionally they must be able to create cipher-text on "drive-by" computers, not connected to the public network or where any network access is raising undesired attention . It is essential that the software requires no "installation" on the computer it is to be used on. (i.e., it must be statically linked, with no external dependencies). >> ... This file is encrypted with operator's public key... >this probably will not be possible ... Yes (clumsily worded in the OP). Obviously, operator's private key can't be "encrypted with itself" - it will have to be encrypted with a pass-phrase generated key, just as it is in gpg. Peter M. From shavital at gmail.com Tue Jul 31 21:15:49 2012 From: shavital at gmail.com (Charly Avital) Date: Tue, 31 Jul 2012 15:15:49 -0400 Subject: message signature types In-Reply-To: References: Message-ID: <50182EE5.2030103@gmail.com> auto15963931 July 31, 2012 2:47:22 PM wrote: > If this is the wrong place to ask, please point me in the right > direction. Where can I learn more about importing, if such a thing is > even done this way, and making use of message signatures which utilize > an "smime.p7s" file? I got a message from someone who uses this, and I > need to learn about verifying and downloading from a keyserver files > like this. Especially important for me is learning how to check whether > it had been revoked, etc. Where is a support group for this sort of > signature if this is not it? Thanks. S/MIME = Secure Multipurpose Internet Mail Extensions is a standard for public key encryption and signing of e-mail encapsulated in MIME. It achieves goals that are similar to GnuPG's but uses different means. The use of GnuPG requires the installation of GnuPG software, and some kind of module that will enable interaction between that software and the e-mail client one is using. GnuPG per se enables its user to generate and manage certificates (aka keys). S/MIME does not require the installation of any such software but needs to obtain and install a certificate/key that is issued by a Certificate Authority (CA). The certificate that is issued by the CA of your choice has to be imported into your e-mail client (if it has S/MIME capability) or into your browser. You might try . I am sure members of this list will provide more accurate information. Charly OS X 10.8 (12A269} MacBook Intel C2Duo 2GHz-GnuPG 1.4.12-MacGPG2-2.0.17-9 Thunderbird 14.0 Enigmail 1.5a1pre (20120727-2257) From rjh at sixdemonbag.org Tue Jul 31 21:25:00 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 31 Jul 2012 15:25:00 -0400 Subject: gpg "simplified"? In-Reply-To: <5017CCEC.5010103@dfgh.net> References: <50168344.9090000@dfgh.net> <501768E4.8010603@yyy.id.lv> <87ehns6zp7.fsf@vigenere.g10code.de> <5017CCEC.5010103@dfgh.net> Message-ID: <5018310C.6000000@sixdemonbag.org> On 7/31/2012 8:17 AM, peter.segment at wronghead.com wrote: > Correct me if I'm wrong, but it is unreasonable to expect anybody > to successfully and safely use gpg without understanding the > concepts and mastering the skills essential to the WOT: This is not at all the case. Set up a trusted introducer/certificate authority and presto, bang, you're off to the races. When Alice comes on board at the company, the local authority generates a certificate for her, sets up her Thunderbird+Enigmail installation (or choose-your-preferred-MUA), signs her certificate, and has her certificate recognize the CA as a trusted introducer. All Alice needs to do is choose her passphrase. She can now communicate securely with anyone inside the organization. In order to communicate securely with someone outside the organization, she calls up the certificate authority and says, "I need to email some documents to Bob over at another firm. Could you please make this happen?" The CA then calls Bob, does the identity check, fingerprint verification, etc., and at the end of it signs Bob's certificate and introduces Bob's certificate to the local keyserver. The CA calls Alice back and says, "Grab Bob's certificate from the local keyserver: you're good to go." At no point does Alice need to know anything about the Web of Trust. All she needs to know is -- 1. She needs to keep her passphrase secure 2. If she wants to send secure email, she needs to check to see if her recipient's certificate is on the keyserver 3. If it's not, she needs to call the local CA The rest can all be done automatically. > Most users in this group have no single computer they operate on. > Occasionally they must be able to create cipher-text on "drive-by" > computers This cannot be done safely. You must have physical control over the hardware for GnuPG to be used safely. "Drive-by" machines have uncomfortably high malware infection rates. Don't use GnuPG except on machines that you physically control and are confident are free of malware.