From df at dfranke.us Sat May 2 07:42:27 2009 From: df at dfranke.us (Daniel Franke) Date: Fri, 01 May 2009 22:42:27 -0700 Subject: A coming attack on PGP, and a way to mitigate it Message-ID: <87iqkkf4cc.fsf@feanor.dfranke.us> For those who haven't yet heard, it's rumored that a new attack on SHA-1 finds collisions in 2^52 operations. That's on the order of one hour of computation for the Storm botnet. The details of the attack haven't been published yet, but the slides are here: http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf This is not, as best I can tell, a chosen-prefix attack, and therefore does not immediately translate to an attack against OpenPGP. The technical summary of the attack is somewhat beyond my expertise, so I could be mistaken about this in both the antecedent and the inference. If so, it's already time to panic. Regardless, however, I think this discovery should be interpreted as writing on the wall for SHA-1, and we should assume that a practical chosen-prefix attack is imminent. Here's what a chosen-prefix collision would allow. Suppose that Alice trusts Trent to sign PGP keys. Per GnuPG's default settings, Trent's key is 1024-bit DSA with a 160-bit 'q' parameter, so it uses SHA-1 for a hash algorithm. Suppose that Mallory wants to send Alice a message impersonating Bob. So, Mallory generates two new keys, one with his name on it and the other with Bob's, such that Trent's signature packets for each would have the same SHA-1 digest. Then, he takes the key with his own name on it over to Trent along with his passport, and Trent checks Mallory's credentials and dutifully signs the key. Then Mallory wanders off, copies Trent's signature onto to the fake key that has Bob's name on it, and uses it to sign a message addressed to Alice. (n.b., this is basically the same approach as the attack that produced a rogue PKI CA last December, using an MD5 collision: http://www.win.tue.nl/hashclash/rogue-ca/) A necessary precondition for this attack to succeed is that the contents of the packet that Trent signs be predictable. Right now, they are. Guessing the signature creation time could be problematic, but if we're relying on that, then that's a hell of a way to run a cryptosystem. However, there's no reason this has to be so. Without breaking backward compatibility, GnuPG could include in every signature packet a hashed 'Notation' subpacket containing a random nonce. Now the SHA-1 digest that Trent signs is no longer predictable in advance, so if Mallory wants to find a collision, he needs a preimage attack rather than just a birthday attack. This is much more difficult. This seems like a worthwhile precaution regardless of the strength of the hash algorithm being used. -- Daniel Franke df at dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dshaw at jabberwocky.com Sat May 2 16:41:46 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 2 May 2009 10:41:46 -0400 Subject: the "pgp" trust model: the relationship between classic ownertrust designation and trust signatures In-Reply-To: <49F8C6AE.1030205@fifthhorseman.net> References: <49F89DEF.6070301@fifthhorseman.net> <4D9B3A31-1D65-4260-B3F1-6746155EDDD8@jabberwocky.com> <49F8BF73.6060604@fifthhorseman.net> <80D64330-0B74-4373-95B0-12D7BD6462EA@jabberwocky.com> <49F8C6AE.1030205@fifthhorseman.net> Message-ID: On Apr 29, 2009, at 5:29 PM, Daniel Kahn Gillmor wrote: > On 04/29/2009 05:21 PM, David Shaw wrote: >> An (implied) infinite trust >> signature from Alice on Baker would be a fairly dangerous thing. It >> gives Baker vastly more power than he would have in the classic trust >> model. In classic, he could just sign one level down from >> himself. In >> pgp, he could make introducers of introducers of introducers, down to >> whatever level he wanted. For safety, it's best to require Alice to >> explicitly grant that kind of power. > > This reasoning makes a lot of sense, and i'm glad that gnupg > implements > it this way now that it's been explained to me. :P > >>> Does --max-cert-depth have any meaning outside of the "pgp" trust >>> model >>> for gpg? If not, why do we need it as an explicitly separate value, >>> since each trust signature made by the ultimately-trusted key would >>> imply a more-specific cert-depth limit anyway? >> >> --max-cert-depth is used in both the classic and pgp trust models. > > How does max-cert-depth work in the classic trust model? I'm afraid i > don't understand how a chain of length > 1 can exist in that model. > What am i missing? It's not really a chain in the pgp trust model sense. Take the example of a simple row of keys that sign the next key: Alice signs Baker who signs Charlie who signs David who signs Edgar who signs Gloria. Alice then gives full ownertrust to Baker, Charlie, David, and Edgar. End result is that Gloria is fully valid, *if* the max- cert-depth is deep enough to cover her, if not, then Edgar's signature has no effect. >> You are right that a "pure" trust >> model does imply a --max-cert-depth of infinity. It's just that we >> don't live in a pure world. > > Should there be warnings, then, when issuing a trust-sig with a level > greater than max-cert-depth? Or should you need to have --expert > enabled to do so? There's no current indication that creating such a > signature won't have the intended effect. It's hard to do that since the two concepts live on the opposite sides of the key signing "transaction". The signer picks the trust-sig levels, but the recipient has their own personal choice for max-cert- depth, and each recipient can pick a different one. GPG handles this by letting the signer issue signatures as if max-cert- depth was always infinite ("this is the validity I choose to grant"), but allows the recipient to trim that down to whatever they like ("this is what I will accept"). The default max-cert-depth is 5. David From dkg at fifthhorseman.net Sat May 2 17:02:07 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 02 May 2009 11:02:07 -0400 Subject: the "pgp" trust model: the relationship between classic ownertrust designation and trust signatures In-Reply-To: References: <49F89DEF.6070301@fifthhorseman.net> <4D9B3A31-1D65-4260-B3F1-6746155EDDD8@jabberwocky.com> <49F8BF73.6060604@fifthhorseman.net> <80D64330-0B74-4373-95B0-12D7BD6462EA@jabberwocky.com> <49F8C6AE.1030205@fifthhorseman.net> Message-ID: <49FC606F.3070509@fifthhorseman.net> On 05/02/2009 10:41 AM, David Shaw wrote: > On Apr 29, 2009, at 5:29 PM, Daniel Kahn Gillmor wrote: >> How does max-cert-depth work in the classic trust model? I'm afraid i >> don't understand how a chain of length > 1 can exist in that model. >> What am i missing? > > It's not really a chain in the pgp trust model sense. Take the example > of a simple row of keys that sign the next key: Alice signs Baker who > signs Charlie who signs David who signs Edgar who signs Gloria. Alice > then gives full ownertrust to Baker, Charlie, David, and Edgar. End > result is that Gloria is fully valid, *if* the max-cert-depth is deep > enough to cover her, if not, then Edgar's signature has no effect. Ah, i see. So it's measured from the nearest key/uid directly signed by an ultimately-trusted key, right? In the above scenario, if Gloria was one hop too many (i.e. if max-cert-depth was 3), were Alice to sign Charlie's key/uid in addition to having marked the key with full ownertrust, then Gloria's key/uid would have full calculated validity. Do i have that right? > It's hard to do that since the two concepts live on the opposite sides > of the key signing "transaction". The signer picks the trust-sig > levels, but the recipient has their own personal choice for > max-cert-depth, and each recipient can pick a different one. > > GPG handles this by letting the signer issue signatures as if > max-cert-depth was always infinite ("this is the validity I choose to > grant"), but allows the recipient to trim that down to whatever they > like ("this is what I will accept"). The default max-cert-depth is 5. OK, i understand the reasoning here. It still seems to me like it would usually be unreasonable for a person whose own max-cert-depth was 5 to issue a tsig with depth > 5 (which is why i suggested a warning rather than disabling the feature), but i see how it might come in handy in some circumstances. Thanks for the explanations of these concepts, David. It's very helpful. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun May 3 01:43:41 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 02 May 2009 19:43:41 -0400 Subject: removing SHA1 from digest preference list Message-ID: <49FCDAAD.2050000@fifthhorseman.net> Hi folks-- In light of the recent SHA1 advances, i thought i'd look into what it would take to remove SHA1 from my list of preferred ciphers for a given key. it seems that gpg2 automatically enables SHA1 (albeit at the end of the list of preferred digests (hash functions). (it also automatically includes 3DES in the list of preferred ciphers, for some reason). For example: > Command> setpref AES256 TWOFISH ZLIB BZIP2 ZIP Uncompressed SHA512 SHA384 SHA256 SHA224 > Set preference list to: > Cipher: AES256, TWOFISH, 3DES > Digest: SHA512, SHA384, SHA256, SHA224, SHA1 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > Features: MDC, Keyserver no-modify > Really update the preferences? (y/N) I don't see anything in the RFC to indicate that SHA1 must be included in the list of preferred hashes: http://tools.ietf.org/html/rfc4880#section-5.2.3.8 http://tools.ietf.org/html/rfc4880#section-9.4 suggests that compliant implementations must *implement* SHA-1. But the earlier section suggests that the list of digest algorithms indicates "Message digest algorithm numbers that indicate which algorithms the key holder prefers to receive." I no longer prefer to receive SHA-1 (well, i don't understand the nuances of the latest report yet, so i'm not really at this extreme position right now, but i might want to adopt it sooner than i had expected to). I'd like to be able to make that statement explicit if possible, even though i use an RFC-compliant tool. There's no reason to force-include MD5 in the list of digests, for example, even though gnupg is capable of implementing it, right? If the recent results have any practical traction, it seems like we might want to be able to exclude SHA1 in the same way that we currently exclude MD5, no? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sun May 3 02:43:17 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 2 May 2009 20:43:17 -0400 Subject: removing SHA1 from digest preference list In-Reply-To: <49FCDAAD.2050000@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> Message-ID: <30538957-C773-41DD-B535-4E28DD9BC4FE@jabberwocky.com> On May 2, 2009, at 7:43 PM, Daniel Kahn Gillmor wrote: > Hi folks-- > > In light of the recent SHA1 advances, i thought i'd look into what it > would take to remove SHA1 from my list of preferred ciphers for a > given key. > > it seems that gpg2 automatically enables SHA1 (albeit at the end of > the > list of preferred digests (hash functions). (it also automatically > includes 3DES in the list of preferred ciphers, for some reason). For > example: > >> Command> setpref AES256 TWOFISH ZLIB BZIP2 ZIP Uncompressed SHA512 >> SHA384 SHA256 SHA224 >> Set preference list to: >> Cipher: AES256, TWOFISH, 3DES >> Digest: SHA512, SHA384, SHA256, SHA224, SHA1 >> Compression: ZLIB, BZIP2, ZIP, Uncompressed >> Features: MDC, Keyserver no-modify >> Really update the preferences? (y/N) > > I don't see anything in the RFC to indicate that SHA1 must be included > in the list of preferred hashes: It's in section 13.3.2. Hash Algorithm Preferences: Since SHA1 is the MUST-implement hash algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. There is similar language about 3DES in the cipher list (section 13.2). In other words, GPG is not required to tell people it's there, but it is required to put it there. GPG does tell people it's there as this is less confusing than it would be if someone saw 3DES was selected and had no idea why. The basic idea behind all this is that it guarantees the the preference system can always succeed: even if two keyholders completely disagree on every possible algorithm choice, they must eventually agree on 3DES / SHA-1 / Uncompressed. So the bottom line is that you can't remove it. It's inherent in the protocol. You can certainly rank it lower than other algorithms if you want to, though (as in your example above). > There's no reason to force-include MD5 in the list of digests, for > example, even though gnupg is capable of implementing it, right? If > the > recent results have any practical traction, it seems like we might > want > to be able to exclude SHA1 in the same way that we currently exclude > MD5, no? Unfortunately, OpenPGP has a few spots where SHA-1 is hardwired into the design. For example, key fingerprints are SHA-1, and cannot be anything else. This will eventually change - even before this recent SHA-1 problems, the writing was on the wall for SHA-1. Even a completely un-cracked SHA-1 was scheduled to "expire" off the NIST algorithm list after 2010. My main advice for people concerned about the SHA-1 problem is to migrate away from 1024-bit DSA keys, as these keys require a 160 bit hash (i.e. SHA-1 or RIPEMD/160). You can replace the keys with either DSA2 keys (i.e. DSA keys that are larger than 1024 bits) or RSA keys (there are various arguments for either choice here). Either way, there is no need to go crazy and frantically revoke 1024-bit DSA keys, but you should at least have a migration plan. David From dshaw at jabberwocky.com Sun May 3 04:23:02 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 2 May 2009 22:23:02 -0400 Subject: the "pgp" trust model: the relationship between classic ownertrust designation and trust signatures In-Reply-To: <49FC606F.3070509@fifthhorseman.net> References: <49F89DEF.6070301@fifthhorseman.net> <4D9B3A31-1D65-4260-B3F1-6746155EDDD8@jabberwocky.com> <49F8BF73.6060604@fifthhorseman.net> <80D64330-0B74-4373-95B0-12D7BD6462EA@jabberwocky.com> <49F8C6AE.1030205@fifthhorseman.net> <49FC606F.3070509@fifthhorseman.net> Message-ID: <2D94CA68-6862-40D9-9EAB-4FC2564DF3B9@jabberwocky.com> On May 2, 2009, at 11:02 AM, Daniel Kahn Gillmor wrote: > On 05/02/2009 10:41 AM, David Shaw wrote: >> On Apr 29, 2009, at 5:29 PM, Daniel Kahn Gillmor wrote: >>> How does max-cert-depth work in the classic trust model? I'm >>> afraid i >>> don't understand how a chain of length > 1 can exist in that model. >>> What am i missing? >> >> It's not really a chain in the pgp trust model sense. Take the >> example >> of a simple row of keys that sign the next key: Alice signs Baker who >> signs Charlie who signs David who signs Edgar who signs Gloria. >> Alice >> then gives full ownertrust to Baker, Charlie, David, and Edgar. End >> result is that Gloria is fully valid, *if* the max-cert-depth is deep >> enough to cover her, if not, then Edgar's signature has no effect. > > Ah, i see. So it's measured from the nearest key/uid directly > signed by > an ultimately-trusted key, right? In the above scenario, if Gloria > was > one hop too many (i.e. if max-cert-depth was 3), were Alice to sign > Charlie's key/uid in addition to having marked the key with full > ownertrust, then Gloria's key/uid would have full calculated validity. > Do i have that right? If max-cert-depth was 3, then the trusted keys would be Alice (of course), Baker, Charlie, and David (i.e. 3 hops from Alice), so Gloria would be 2 hops too many. If Alice were to sign Charlie, Gloria wouldn't be trusted as that is 4 hops (Alice -> Charlie -> David -> Edgar -> Gloria). Take your example, and make it max-cert-depth 4, instead of 3, and you've got it. >> It's hard to do that since the two concepts live on the opposite >> sides >> of the key signing "transaction". The signer picks the trust-sig >> levels, but the recipient has their own personal choice for >> max-cert-depth, and each recipient can pick a different one. >> >> GPG handles this by letting the signer issue signatures as if >> max-cert-depth was always infinite ("this is the validity I choose to >> grant"), but allows the recipient to trim that down to whatever they >> like ("this is what I will accept"). The default max-cert-depth is >> 5. > > OK, i understand the reasoning here. It still seems to me like it > would > usually be unreasonable for a person whose own max-cert-depth was 5 to > issue a tsig with depth > 5 (which is why i suggested a warning rather > than disabling the feature), but i see how it might come in handy in > some circumstances. > > Thanks for the explanations of these concepts, David. It's very > helpful. Glad to help! David From jmoore3rd at bellsouth.net Sun May 3 05:26:29 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sat, 02 May 2009 23:26:29 -0400 Subject: removing SHA1 from digest preference list In-Reply-To: <49FCDAAD.2050000@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> Message-ID: <49FD0EE5.50809@bellsouth.net> Daniel Kahn Gillmor wrote: > Hi folks-- > > In light of the recent SHA1 advances, i thought i'd look into what it > would take to remove SHA1 from my list of preferred ciphers for a given key. > I don't see anything in the RFC to indicate that SHA1 must be included > in the list of preferred hashes: It falls under the heading of Compatibility; particularly with regards to backward compatibility. > http://tools.ietf.org/html/rfc4880#section-9.4 suggests that compliant > implementations must *implement* SHA-1. But the earlier section > suggests that the list of digest algorithms indicates "Message digest > algorithm numbers that indicate which algorithms the key holder prefers > to receive." I no longer prefer to receive SHA-1 (well, i don't > understand the nuances of the latest report yet, so i'm not really at > this extreme position right now, but i might want to adopt it sooner > than i had expected to). I'd like to be able to make that statement > explicit if possible, even though i use an RFC-compliant tool. Until such time as OpenPGP implementations completely abandon backwards compatibility SHA1 will be recognized & 'accepted'; just as MD5 is at present. Removing it from Your Preference List will only mean that everyone who Imports Your Key after You make the change will recognize that You prefer _not_ to use SHA1; but everyone who already has Your Key on their Keyring will still be encrypting to a Key that states SHA1 in it's Preferences. Even the Key Servers will be propagating Your Key with SHA1 'advertised'. Generating a New Key at the present time will not erase this as every OpenPGP Application I am aware of at present includes SHA1 by default. SHA1, at present, is the de facto Standard hash to ensure that Encryption to multiple Keys using various OpenPGP engines will /always/ have a compatible Hash. Also to consider is that, at present, the Default Key for GPG & PGP is a 1024 DSA Key. Should You be successful in implementing an installation that cannot or refuses to recognize SHA1 You will be cutting Yourself off from being able to verify the overwhelming majority of Signatures that You encounter. :-\ > There's no reason to force-include MD5 in the list of digests, for > example, even though gnupg is capable of implementing it, right? If the > recent results have any practical traction, it seems like we might want > to be able to exclude SHA1 in the same way that we currently exclude > MD5, no? Exclude? Even if MD5 isn't listed in the Preferences it is still recognized and accepted by all OpenPGP Applications. Battleships don't U-turn in 100 yards and neither does Software. Look at how long it took for MD5 to become unused. The only Hash that I am aware of that has actually been excluded is TIGER192 and even that Hash can be seen occasionally. With the vast repository of Keys generated over 20 years coupled with the number of folks who continue to use deprecated builds of PGP & GPG discarding SHA1 is not going to be as simple as throwing a switch. This is what folks are alluding to when they say Move in an orderly fashion toward the theater exits. To promptly abandon SHA1 immediately is akin to shouting Fire in a crowded theater. Ostracizing SHA1 will be no simple task. JOHN 8-) Timestamp: Saturday 02 May 2009, 23:26 --400 (Eastern Daylight Time) . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From df at dfranke.us Sun May 3 12:24:00 2009 From: df at dfranke.us (Daniel Franke) Date: Sun, 03 May 2009 03:24:00 -0700 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: <87iqkkf4cc.fsf@feanor.dfranke.us> (sfid-20090501_231607_696644_1D24B249) (Daniel Franke's message of "Fri, 01 May 2009 22:42:27 -0700") References: <87iqkkf4cc.fsf@feanor.dfranke.us> Message-ID: <87eiv6fprz.fsf@feanor.dfranke.us> I wrote: > A necessary precondition for this attack to succeed is that the contents > of the packet that Trent signs be predictable. Right now, they are. > Guessing the signature creation time could be problematic, but if we're > relying on that, then that's a hell of a way to run a cryptosystem. > However, there's no reason this has to be so. Without breaking backward > compatibility, GnuPG could include in every signature packet a hashed > 'Notation' subpacket containing a random nonce. Now the SHA-1 digest > that Trent signs is no longer predictable in advance, so if Mallory > wants to find a collision, he needs a preimage attack rather than just a > birthday attack. This is much more difficult. > > This seems like a worthwhile precaution regardless of the strength of > the hash algorithm being used. *Sigh*. Unfortunately, I have to retract this, due to my earlier misreading of RFC4880. The order of the data being hashed is first the signee's key packet, then his userid, then the signature packet constructed by the signer. So first of all, what Mallory actually needs is a chosen-*suffix* attack, not a chosen prefix, since the userids (which need to be chosen) come after the key packets (which can be mostly random). More important, though, is that everything that can be customized by the signer comes after the parts that the signer is authenticating. Since SHA-1 does only a single pass over the data, this means that once Mallory finds a collision over the parts that he wants to forge (the key and userid), what comes after them is irrelevant as long as it is the same on the legitimate key as the forged one. So even without knowing in advance what digest Trent is going to sign, Mallory can get a valid forgery by copying Trent's nonce onto the forged key along with Trent's signature. This also means that my previous remark about the possible difficulty of predicting the creation time offers no mitigation at all. It still seems that the idea of dispersing signer-chosen random bytes throughout the input to the hash could mitigate many sorts of likely future attacks against SHA-1 or other hash algorithms. This though is useless to us at present, since it could not be implemented in anything resembling a backward-compatible manner, and once we're willing to forget about backwards compatibility we can simply banish SHA-1. -- Daniel Franke df at dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun May 3 18:56:48 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 03 May 2009 12:56:48 -0400 Subject: removing SHA1 from digest preference list In-Reply-To: <49FD0EE5.50809@bellsouth.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> Message-ID: <49FDCCD0.10300@fifthhorseman.net> On 05/02/2009 11:26 PM, John W. Moore III wrote: > It falls under the heading of Compatibility; particularly with regards > to backward compatibility. Right, understood. > Until such time as OpenPGP implementations completely abandon backwards > compatibility SHA1 will be recognized & 'accepted'; just as MD5 is at > present. Removing it from Your Preference List will only mean that > everyone who Imports Your Key after You make the change will recognize > that You prefer _not_ to use SHA1; but everyone who already has Your Key > on their Keyring will still be encrypting to a Key that states SHA1 in > it's Preferences. I understand that this process of preference propagation may be imperfect and incomplete, and may take a long time. This is precisely why i wish to start it as soon as possible. > Even the Key Servers will be propagating Your Key > with SHA1 'advertised'. Can you explain this? If i look at my current key on the keyservers, it appears that the latest self-signature says "(pref-hash-algos: 10 9 8 11)". This does not include hash algorithm 2, which is sha1, and since the latest signature is presumed to supercede the previous ones, it looks to me like the keyservers are already *not* propagating my key with SHA1 "advertised". What am i misinterpreting? I got this information with the following pipeline: wget -O- "http://keys.gnupg.net:11371/pks/lookup?op=get&search=$KEYID" | awk '/^$/{KEY=1}; /^-/{KEY=0} { if (KEY) { print $0 ; } }' | base64 -d | gpg --list-packets > Generating a New Key at the present time will not erase this as every > OpenPGP Application I am aware of at present includes SHA1 by default. > SHA1, at present, is the de facto Standard hash to ensure that > Encryption to multiple Keys using various OpenPGP engines will /always/ > have a compatible Hash. I understand this. However, at one point, the one hash algorithm that everyone would /always/ have available was probably MD2 or something else that is currently demonstrably broken today. This is not a good reason for us to use MD2 today, and it will not be a good reason for us to use SHA1 several years from now. > Also to consider is that, at present, the > Default Key for GPG & PGP is a 1024 DSA Key. Should You be successful > in implementing an installation that cannot or refuses to recognize SHA1 > You will be cutting Yourself off from being able to verify the > overwhelming majority of Signatures that You encounter. :-\ Yes, i'm aware. I'm not talking about completely rejecting all SHA1 signatures right now. I'm talking about signalling my intent to deprecate SHA1, so that those with whom i correspond have a signal to begin transitioning to a better hash *before* i decide to abandon it. > Exclude? Even if MD5 isn't listed in the Preferences it is still > recognized and accepted by all OpenPGP Applications. If this is true (i haven't tested it), i'd like to see that change. i'd like at least to be able to tell gpg "please consider as invalid any credentials dependent upon an MD5 digest" and have it respect that. I'll try to test this out today. > discarding SHA1 is not going to be as simple as throwing a > switch. This is what folks are alluding to when they say Move in an > orderly fashion toward the theater exits. To promptly abandon SHA1 > immediately is akin to shouting Fire in a crowded theater. > Ostracizing SHA1 will be no simple task. Sigh. I totally agree. This is exactly why we need to be having this discussion now, so that the theater exits will have lighted signs and arrows with clear directions as people start to get out of their seats. I want to make sure the mechanisms are all in place and properly documented *before* a practical demonstration of the described vulnerabilities exists in the wild. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon May 4 02:48:55 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 03 May 2009 20:48:55 -0400 Subject: un-trusting MD5 in gpg [was: Re: removing SHA1 from digest preference list] In-Reply-To: <49FDCCD0.10300@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> Message-ID: <49FE3B77.2040900@fifthhorseman.net> On 05/03/2009 12:56 PM, Daniel Kahn Gillmor wrote: > On 05/02/2009 11:26 PM, John W. Moore III wrote: >> Exclude? Even if MD5 isn't listed in the Preferences it is still >> recognized and accepted by all OpenPGP Applications. > > If this is true (i haven't tested it), i'd like to see that change. i'd > like at least to be able to tell gpg "please consider as invalid any > credentials dependent upon an MD5 digest" and have it respect that. > I'll try to test this out today. I just tested this, and i have not been able to find a way to convince gpg to treat MD5-digested certifications as untrustworthy. :( I have not even been able to get gpg to issue a warning when checking signatures using a known-broken digest algorithm (for example, when doing check-sigs, even --with-colons --fixed-list-mode). Does anyone know of a way to tell gnupg to ignore certifications based on a particular digest algorithm? Most modern TLS implementations have adopted mechanisms to distrust signatures made over deprecated digest algorithms, so i don't think this is a terribly unusual goal. I just don't see how to get there in gnupg without modifying the source. Any pointers? Gnupg warns when *creating* md5 signatures, but that doesn't protect against signatures that already exist, and it doesn't seem to protect against interpreting or trusting signatures that rely on this known-broken digest algorithm. To be clear: i'm not looking to tell gnupg today "do not trust SHA1 digests," but i *am* looking to tell gnupg today "do not trust MD5 digests". I'm willing to take that risk of cutting myself off from older implementations with respect to MD5. And i'm interested in seeing what the consequences will be of taking such an action. Suggestions for how to go about doing this with gnupg? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon May 4 04:24:55 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 03 May 2009 22:24:55 -0400 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: <87iqkkf4cc.fsf@feanor.dfranke.us> References: <87iqkkf4cc.fsf@feanor.dfranke.us> Message-ID: <49FE51F7.80609@fifthhorseman.net> On 05/02/2009 01:42 AM, Daniel Franke wrote: > A necessary precondition for this attack to succeed is that the contents > of the packet that Trent signs be predictable. Right now, they are. > Guessing the signature creation time could be problematic, but if we're > relying on that, then that's a hell of a way to run a cryptosystem. > However, there's no reason this has to be so. Without breaking backward > compatibility, GnuPG could include in every signature packet a hashed > 'Notation' subpacket containing a random nonce. Now the SHA-1 digest > that Trent signs is no longer predictable in advance, so if Mallory > wants to find a collision, he needs a preimage attack rather than just a > birthday attack. This is much more difficult. This is not a bad idea, and i think it is already possible, actually, though not as easy to automate as it could be. Maybe it would be helpful to standardize on a name for the nonce notation as well? Werner (or anyone else responsible for the gnupg.org domain), would nonce at gnupg.org be acceptable for use? Or if you're looking to isolate the gnupg-related notation namsepace, maybe nonce at notations.gnupg.org ? The way you could do this currently would be something like: NONCE="nonce at gnupg.org=$(head -c 20 /dev/random | base64) gpg --sign-key --set-notation "$NONCE" $KEYID (note: use --sig-notation or --cert-notation if you only want this to affect a data signature or key signature, respectively. --set-notation covers both) So what's missing in terms of automation is the ability to get gpg to automatically include a nonce or any other generated content. for example, it'd be nice to be able to throw a line like this into ~/.gnupg/gpg.conf: set-notation nonce at gnupg.org=$(head -c 20 /dev/random | base64) and have it do what i mean here. If this embedding of shell output seems too dangerous or crazy, another option would be to add to the special codes in notations (gpg(1) implies that the special codes are only used in notation names, but they seem to work in notation values as well): perhaps %n would be a 160-bit nonce, base64-encoded? Does anyone else think this feature would be useful? I could take a shot at writing a patch for either proposed behavior above if people are interested. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon May 4 04:41:49 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 3 May 2009 22:41:49 -0400 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: <87iqkkf4cc.fsf@feanor.dfranke.us> References: <87iqkkf4cc.fsf@feanor.dfranke.us> Message-ID: On May 2, 2009, at 1:42 AM, Daniel Franke wrote: > A necessary precondition for this attack to succeed is that the > contents > of the packet that Trent signs be predictable. Right now, they are. > Guessing the signature creation time could be problematic, but if > we're > relying on that, then that's a hell of a way to run a cryptosystem. > However, there's no reason this has to be so. Without breaking > backward > compatibility, GnuPG could include in every signature packet a hashed > 'Notation' subpacket containing a random nonce. Now the SHA-1 digest > that Trent signs is no longer predictable in advance, so if Mallory > wants to find a collision, he needs a preimage attack rather than > just a > birthday attack. This is much more difficult. I rather like this idea. I was thinking that a good way to tie it into the GPG way of doing things would be another one of the %- expandos. So you could do something like set a notation for "random at example.com =%10r" for 10 digits of random hex, %15r for 15 digits, etc. Before we go down this road, however, it might be worth waiting the (should be short) period of time before the new SHA-1 paper is formally published and people can give it a good read over. The slides are good, but I think it's healthy to get a better notion of the attack before we implement a countermeasure (even one as harmless to compatibility as this). > This seems like a worthwhile precaution regardless of the strength of > the hash algorithm being used. True. It's a very neat idea. David From dshaw at jabberwocky.com Mon May 4 04:44:04 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 3 May 2009 22:44:04 -0400 Subject: un-trusting MD5 in gpg [was: Re: removing SHA1 from digest preference list] In-Reply-To: <49FE3B77.2040900@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> Message-ID: <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> On May 3, 2009, at 8:48 PM, Daniel Kahn Gillmor wrote: > Gnupg warns when *creating* md5 signatures, but that doesn't protect > against signatures that already exist, and it doesn't seem to protect > against interpreting or trusting signatures that rely on this > known-broken digest algorithm. > > To be clear: i'm not looking to tell gnupg today "do not trust SHA1 > digests," but i *am* looking to tell gnupg today "do not trust MD5 > digests". I'm willing to take that risk of cutting myself off from > older implementations with respect to MD5. And i'm interested in > seeing > what the consequences will be of taking such an action. There is no way to do this aside from modifying the source. It's a interesting idea, though. At a minimum, it would imply cutting yourself off from most, if not all, PGP 2.x support. I somewhat suspect it would also affect some versions of PGP that are newer than PGP 2.x, but yet aren't quite OpenPGPish (say, PGP 5 and 6 as they can sometimes use old format packets that might expect MD5). It would certainly break the GPG selftest as that expects MD5 to be present in a number of places. Funny, now that I think about it more, it doesn't really break all that much. As a community, we've done a pretty good job of removing MD5 from our lives. The main problem is that the GPG code isn't really built with the concept that MD5 might suddenly not be available. That's changeable, of course (the selftest can be fixed, etc), but it's not trivial. > Suggestions for how to go about doing this with gnupg? Try this patch (against the 1.4 branch): Index: g10/sig-check.c =================================================================== --- g10/sig-check.c (revision 4987) +++ g10/sig-check.c (working copy) @@ -60,6 +60,9 @@ PKT_public_key *pk = xmalloc_clear( sizeof *pk ); int rc=0; + if(sig->digest_algo==DIGEST_ALGO_MD5) + return G10ERR_BAD_SIGN; + if( (rc=check_digest_algo(sig->digest_algo)) ) ; /* we don't have this digest */ else if((rc=check_pubkey_algo(sig->pubkey_algo))) That will artificially cause any signature made with MD5 to not verify. Alternately (and a far more drastic change), in cipher/md.c there is a function load_digest_module(). In it there are two lines that read: if (!new_list_item (DIGEST_ALGO_MD5, md5_get_info)) BUG (); Remove or comment out those two lines. This second method actually removes MD5 completely from GPG. It will likely break in more places than the signature hack (for example --print-mds won't work, etc). I'd be very interested to hear how well you get on without MD5. David From dshaw at jabberwocky.com Mon May 4 05:11:44 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 3 May 2009 23:11:44 -0400 Subject: un-trusting MD5 in gpg [was: Re: removing SHA1 from digest preference list] In-Reply-To: <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> Message-ID: <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> On May 3, 2009, at 10:44 PM, David Shaw wrote: > >> Suggestions for how to go about doing this with gnupg? > > Try this patch (against the 1.4 branch): Better patch: Index: g10/sig-check.c =================================================================== --- g10/sig-check.c (revision 4987) +++ g10/sig-check.c (working copy) @@ -60,6 +60,9 @@ PKT_public_key *pk = xmalloc_clear( sizeof *pk ); int rc=0; + if(sig->digest_algo==DIGEST_ALGO_MD5) + return G10ERR_BAD_SIGN; + if( (rc=check_digest_algo(sig->digest_algo)) ) ; /* we don't have this digest */ else if((rc=check_pubkey_algo(sig->pubkey_algo))) @@ -522,6 +525,10 @@ sig = node->pkt->pkt.signature; algo = sig->digest_algo; + if(algo==DIGEST_ALGO_MD5) + return G10ERR_BAD_SIGN; + + /* Check whether we have cached the result of a previous signature check. Note that we may no longer have the pubkey or hash needed to verify a sig, but can still use the cached value. A David From df at dfranke.us Mon May 4 05:13:35 2009 From: df at dfranke.us (Daniel Franke) Date: Sun, 03 May 2009 20:13:35 -0700 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: (sfid-20090503_194152_854956_29C80828) (David Shaw's message of "Sun, 3 May 2009 22:41:49 -0400") References: <87iqkkf4cc.fsf@feanor.dfranke.us> Message-ID: <87tz41ef1c.fsf@feanor.dfranke.us> David Shaw writes: > I rather like this idea. I was thinking that a good way to tie it > into the GPG way of doing things would be another one of the %- > expandos. So you could do something like set a notation for > "random at example.com > =%10r" for 10 digits of random hex, %15r for 15 digits, etc. > > Before we go down this road, however, it might be worth waiting the > (should be short) period of time before the new SHA-1 paper is > formally published and people can give it a good read over. The > slides are good, but I think it's healthy to get a better notion of > the attack before we implement a countermeasure (even one as harmless > to compatibility as this). I wrote a followup last night retracting this idea, as it isn't quite going to work. For some reason though, it never got redelivered back to me even though it's in the ML archive: http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024967.html Did you receive it but overlook it before writing this response, or did it get dropped? Leaving this message unsigned in case the signature has something to do with screwing up delivery. -- Daniel Franke df at dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire From dshaw at jabberwocky.com Mon May 4 05:35:59 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 3 May 2009 23:35:59 -0400 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: <87tz41ef1c.fsf@feanor.dfranke.us> References: <87iqkkf4cc.fsf@feanor.dfranke.us> <87tz41ef1c.fsf@feanor.dfranke.us> Message-ID: <123AB642-91ED-43C6-BBBB-3D184463E907@jabberwocky.com> On May 3, 2009, at 11:13 PM, Daniel Franke wrote: > David Shaw writes: > >> I rather like this idea. I was thinking that a good way to tie it >> into the GPG way of doing things would be another one of the %- >> expandos. So you could do something like set a notation for >> "random at example.com >> =%10r" for 10 digits of random hex, %15r for 15 digits, etc. >> >> Before we go down this road, however, it might be worth waiting the >> (should be short) period of time before the new SHA-1 paper is >> formally published and people can give it a good read over. The >> slides are good, but I think it's healthy to get a better notion of >> the attack before we implement a countermeasure (even one as harmless >> to compatibility as this). > > I wrote a followup last night retracting this idea, as it isn't quite > going to work. For some reason though, it never got redelivered back > to me even though it's in the ML archive: > > http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024967.html Drat, I made the same error. The nonce would have to be much earlier in the stream of bits being hashed to be useful. Ah well, it was too good to be true :) > Did you receive it but overlook it before writing this response, or > did it get dropped? Interesting. I never got it at all. David From df at dfranke.us Mon May 4 07:06:04 2009 From: df at dfranke.us (Daniel Franke) Date: Sun, 03 May 2009 22:06:04 -0700 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: <123AB642-91ED-43C6-BBBB-3D184463E907@jabberwocky.com> (sfid-20090503_203602_471793_FFFFFFFF8236ECFF) (David Shaw's message of "Sun, 3 May 2009 23:35:59 -0400") References: <87iqkkf4cc.fsf@feanor.dfranke.us> <87tz41ef1c.fsf@feanor.dfranke.us> <123AB642-91ED-43C6-BBBB-3D184463E907@jabberwocky.com> Message-ID: <87eiv5e9tv.fsf@feanor.dfranke.us> David Shaw writes: > Drat, I made the same error. The nonce would have to be much earlier > in the stream of bits being hashed to be useful. Ah well, it was too > good to be true :) It's a pity, really. We're foiled by what's almost certainly nothing more than a thoughtless accident in the design of the protocol. Perhaps this remains something to consider for the next protocol revision. I can't think of any fundamental reason that PGP must necessarily be exploitable by birthday attacks of any sort, although I'm talking somewhat out of my depth in making this assertion. >> Did you receive it but overlook it before writing this response, or >> did it get dropped? > > Interesting. I never got it at all. Curse you, Mallory -- I know you're reading this! -- Daniel Franke df at dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From df at dfranke.us Mon May 4 07:11:07 2009 From: df at dfranke.us (Daniel Franke) Date: Sun, 03 May 2009 22:11:07 -0700 Subject: A coming attack on PGP, and a way to mitigate it In-Reply-To: <87eiv5e9tv.fsf@feanor.dfranke.us> (sfid-20090503_220725_738258_7F0A32AA) (Daniel Franke's message of "Sun, 03 May 2009 22:06:04 -0700") References: <87iqkkf4cc.fsf@feanor.dfranke.us> <87tz41ef1c.fsf@feanor.dfranke.us> <123AB642-91ED-43C6-BBBB-3D184463E907@jabberwocky.com> <87eiv5e9tv.fsf@feanor.dfranke.us> Message-ID: <877i0xe9lg.fsf@feanor.dfranke.us> I wrote: > It's a pity, really. We're foiled by what's almost certainly nothing > more than a thoughtless accident in the design of the protocol. Perhaps > this remains something to consider for the next protocol revision. I > can't think of any fundamental reason that PGP must necessarily be > exploitable by birthday attacks of any sort, although I'm talking > somewhat out of my depth in making this assertion. Whoa, heh. I just glanced at the authorship of RFC4880 and realized whom I'm addressing :-). -- Daniel Franke df at dfranke.us http://www.dfranke.us |----| =|\ \\\\ || * | -|-\--------- Man is free at the instant he wants to be. -----| =| \ /// --Voltaire -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Mon May 4 10:09:33 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 May 2009 10:09:33 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> (David Shaw's message of "Sun, 3 May 2009 22:44:04 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> Message-ID: <87ab5tthky.fsf@wheatstone.g10code.de> On Mon, 4 May 2009 04:44, dshaw at jabberwocky.com said: > + if(sig->digest_algo==DIGEST_ALGO_MD5) > + return G10ERR_BAD_SIGN; I don't think that this is helpful. It catches one common case but does not catch all the other cases where a signature is used for a malicious purpose. There are many other ways of doing so, for example leaking ones own key. A signature is a statement of the signer about something he believes. We can't force him to believe the Right Thing. Thus giving back an error code of "Bad signature" is wrong. It is a good signature because the signer intended exactly that. The question is how you evaluate such a signature. This is a matter of trust and hard to put in code for a general purpose application, like gpg. What can be done is to print a warning (already on our task list) and to implement an option to ignore signatures done with digest algorithm foo (similar to --disable-cipher-also) Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon May 4 13:16:34 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 07:16:34 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <87ab5tthky.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <87ab5tthky.fsf@wheatstone.g10code.de> Message-ID: <2DDB93C8-FFAE-4CFD-B830-C650C8C7DBB0@jabberwocky.com> On May 4, 2009, at 4:09 AM, Werner Koch wrote: > On Mon, 4 May 2009 04:44, dshaw at jabberwocky.com said: > >> + if(sig->digest_algo==DIGEST_ALGO_MD5) >> + return G10ERR_BAD_SIGN; > > I don't think that this is helpful. It catches one common case but > does > not catch all the other cases where a signature is used for a > malicious > purpose. There are many other ways of doing so, for example leaking > ones own key. A signature is a statement of the signer about > something > he believes. We can't force him to believe the Right Thing. Certainly not. That code is just a hack for Daniel Gillmor to see how feasible it is in practice to run without MD5. It is not at all a rigorous solution to the problem. It's also not at all something appropriate to include in GPG without quite a bit of other work (it breaks half the selftests, causes --print-mds to hit a BUG() case, etc). David From wk at gnupg.org Mon May 4 14:53:45 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 May 2009 14:53:45 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <2DDB93C8-FFAE-4CFD-B830-C650C8C7DBB0@jabberwocky.com> (David Shaw's message of "Mon, 4 May 2009 07:16:34 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <87ab5tthky.fsf@wheatstone.g10code.de> <2DDB93C8-FFAE-4CFD-B830-C650C8C7DBB0@jabberwocky.com> Message-ID: <87ocu9c9ly.fsf@wheatstone.g10code.de> On Mon, 4 May 2009 13:16, dshaw at jabberwocky.com said: > Certainly not. That code is just a hack for Daniel Gillmor to see how > feasible it is in practice to run without MD5. It is not at all a Alright. I just wanted to make sure that nobody takes this as a development plan. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Mon May 4 16:17:22 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 May 2009 10:17:22 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <87ab5tthky.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <87ab5tthky.fsf@wheatstone.g10code.de> Message-ID: <49FEF8F2.4090703@fifthhorseman.net> I'll give David's patch a try shortly, just to see how much of my OpenPGP-related workflow breaks. I'll report back here with anything interesting that i find. Wouldn't it make more sense to return G10ERR_DIGEST_ALGO instead of G10ERR_BAD_SIGN, though? libgpg-error suggests that it means "Invalid Digest Algorithm". Any reason i shouldn't do that instead? On 05/04/2009 04:09 AM, Werner Koch wrote: > What can be done is to print a warning (already on our task list) and to > implement an option to ignore signatures done with digest algorithm foo > (similar to --disable-cipher-also) Yes, something like --disable-digest-algo is the direction i think gpg should be heading. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon May 4 16:40:46 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 10:40:46 -0400 Subject: Changing GPG's default key type Message-ID: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> Hi, Currently, GPG's default key type, the one that is recommended to all new users, is a DSA primary key (1024 bits - not "DSA2") with an Elgamal subkey. We are currently thinking about changing the default primary to a 2048-bit RSA key. The main benefits of changing the key type is that it can go past the 1024 bit DSA1 limit, and would also not be limited to a 160-bit hash, both of which are getting a little long in the tooth. We could get similar benefits with a DSA2 key, but DSA2 is not nearly as widely implemented as RSA is, so is not a good option for a default key at this time. We will of course continue supporting DSA2 (and DSA "1") as we do now. This is purely a question of what the default key should be. This is not directly prompted by the recent SHA-1 troubles, but it is somewhat related, as it would let users of the default key type use hashes larger than 160 bits. That said, this is not intended to be a fix for the SHA-1 problems. We are not proposing changing our default signing hash, which will remain SHA-1. After a bit of internal discussion, we thought it was worth mentioning this here, to see if the community had any issue or other comments. I don't expect this to be a particularly controversial move, but discussion is always welcome. One issue, of course, is that RSA is not a required key type in OpenPGP, so there could be some implementation out there that won't be able to handle it. I'm not terribly concerned about this, as in practice, the vast majority of code has handled RSA just fine for the past decade, and if a particular user needs to generate a non-RSA key, they can still do so. There are a few other details (RSA signatures are physically larger, etc), but I believe they are outweighed by the benefit of the larger key and additional hash flexibility. David From dshaw at jabberwocky.com Mon May 4 16:46:40 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 10:46:40 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <49FEF8F2.4090703@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <87ab5tthky.fsf@wheatstone.g10code.de> <49FEF8F2.4090703@fifthhorseman.net> Message-ID: On May 4, 2009, at 10:17 AM, Daniel Kahn Gillmor wrote: > I'll give David's patch a try shortly, just to see how much of my > OpenPGP-related workflow breaks. I'll report back here with anything > interesting that i find. > > Wouldn't it make more sense to return G10ERR_DIGEST_ALGO instead of > G10ERR_BAD_SIGN, though? libgpg-error suggests that it means "Invalid > Digest Algorithm". Any reason i shouldn't do that instead? Either one is fine for the purpose of this test. The goal is just to temporarily break MD5 to see what happens. Almost any return code will do that. > On 05/04/2009 04:09 AM, Werner Koch wrote: >> What can be done is to print a warning (already on our task list) >> and to >> implement an option to ignore signatures done with digest algorithm >> foo >> (similar to --disable-cipher-also) > > Yes, something like --disable-digest-algo is the direction i think gpg > should be heading. --disable-digest-algo, if implemented the same way as --disable-cipher- algo, implies that the hash won't exist at all for that run. That means it won't be present even for things like --print-md. Is that the intention here? I'm not against it, but I recall seeing a few people using "gpg --print-md md5" as an alternative to "md5sum". We might want to do something more surgical and just block MD5 verification for the OpenPGP operations (though completely removing the hash has the appeal of simplicity). David From dkg at fifthhorseman.net Mon May 4 17:50:33 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 May 2009 11:50:33 -0400 Subject: Changing GPG's default key type In-Reply-To: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> References: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> Message-ID: <49FF0EC9.4090709@fifthhorseman.net> On 05/04/2009 10:40 AM, David Shaw wrote: > Currently, GPG's default key type, the one that is recommended to all > new users, is a DSA primary key (1024 bits - not "DSA2") with an Elgamal > subkey. We are currently thinking about changing the default primary to > a 2048-bit RSA key. I fully support this change. FWIW, openssh has been defaulting to 2048-bit RSA keys for several years now, and has a similarly diverse array of tools with which it must interoperate. I've seen no significant problems reported on openssh-unix-dev since the changeover. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon May 4 19:00:53 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 13:00:53 -0400 Subject: Changing GPG's default key type In-Reply-To: <49FF0EC9.4090709@fifthhorseman.net> References: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> <49FF0EC9.4090709@fifthhorseman.net> Message-ID: <57EAA33A-4DAA-4D9A-8E54-F00BCD214298@jabberwocky.com> On May 4, 2009, at 11:50 AM, Daniel Kahn Gillmor wrote: > On 05/04/2009 10:40 AM, David Shaw wrote: >> Currently, GPG's default key type, the one that is recommended to all >> new users, is a DSA primary key (1024 bits - not "DSA2") with an >> Elgamal >> subkey. We are currently thinking about changing the default >> primary to >> a 2048-bit RSA key. > > I fully support this change. FWIW, openssh has been defaulting to > 2048-bit RSA keys for several years now, and has a similarly diverse > array of tools with which it must interoperate. I've seen no > significant problems reported on openssh-unix-dev since the > changeover. I didn't know it when I first proposed the idea, but it seems that PGP desktop also switched over to a RSA default a version or two back as well. David From dkg at fifthhorseman.net Mon May 4 19:23:47 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 May 2009 13:23:47 -0400 Subject: re-issuing subkey binding signatures with alternate digests Message-ID: <49FF24A3.9000804@fifthhorseman.net> Does anyone know of a way to coax GnuPG (1 or 2) to re-issue existing subkey-binding signatures? I'd like to refresh the signature over an OpenPGP subkey to include different parameters. What parameters? One example would be to add a usage flag. Another (more relevant to my current digest review) would be to change the digest algorithm used on the subkey binding signature (e.g. to re-issue a subkey-binding signature that was originally issued with MD5 to a more acceptable digest). The only way i see to do it is to change the expiration date on the key, which triggers the creation of a new subkey binding signature, but that signature does not seem to respect arguments to --digest-algo or --cert-digest-algo (it seems to currently re-issue the subkey binding signature with SHA1 no matter what --digest-algo or --cert-digest-algo is set to (i've tried with SHA512, SHA256, and MD5, all of which appear to be silently ignored. Is this intentional? Am i doing something wrong? The workflow i've tested is: gpg --digest-algo SHA256 -cert-digest-algo SHA256 edit-key $KEYID key 1 expire 1y save and i view the subkey binding signatures with: gpg --export --export-options export-minimal "0x${SUBKEYID}!" | \ gpg --list-packets --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 4 19:44:08 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 May 2009 19:44:08 +0200 Subject: Changing GPG's default key type In-Reply-To: <57EAA33A-4DAA-4D9A-8E54-F00BCD214298@jabberwocky.com> (David Shaw's message of "Mon, 4 May 2009 13:00:53 -0400") References: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> <49FF0EC9.4090709@fifthhorseman.net> <57EAA33A-4DAA-4D9A-8E54-F00BCD214298@jabberwocky.com> Message-ID: <87ab5sbw5z.fsf@wheatstone.g10code.de> On Mon, 4 May 2009 19:00, dshaw at jabberwocky.com said: > I didn't know it when I first proposed the idea, but it seems that PGP > desktop also switched over to a RSA default a version or two back as > well. Well, so we have to say goodbye to the nice small signature attachments. I think I can live with that. CMS signatures are still far longer. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon May 4 19:41:17 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 May 2009 19:41:17 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: (David Shaw's message of "Mon, 4 May 2009 10:46:40 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <87ab5tthky.fsf@wheatstone.g10code.de> <49FEF8F2.4090703@fifthhorseman.net> Message-ID: <87eiv4bwaq.fsf@wheatstone.g10code.de> On Mon, 4 May 2009 16:46, dshaw at jabberwocky.com said: > might want to do something more surgical and just block MD5 > verification for the OpenPGP operations (though completely removing > the hash has the appeal of simplicity). In fact if you run GPG-2 with libgcrypt in Enforced FIPS mode, this is already the case. The drawback is that you won't have Elganmal either. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon May 4 20:14:36 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 14:14:36 -0400 Subject: re-issuing subkey binding signatures with alternate digests In-Reply-To: <49FF24A3.9000804@fifthhorseman.net> References: <49FF24A3.9000804@fifthhorseman.net> Message-ID: <8BB89690-87A9-4DC9-B1AF-D40EE9AFBCF7@jabberwocky.com> On May 4, 2009, at 1:23 PM, Daniel Kahn Gillmor wrote: > Another (more relevant to my > current digest review) would be to change the digest algorithm used on > the subkey binding signature (e.g. to re-issue a subkey-binding > signature that was originally issued with MD5 to a more acceptable > digest). There is no good way to do this without hackery, but the thing is, you probably don't want to do it that way in any event. Let's say your key was originally generated with SHA-1 as the hash for the subkey binding signature, and you're concerned that an attacker can do nasty things with that binding signature if and when the SHA-1 break is extended. You could probably do various pokings about and force that binding signature to be reissued using SHA-256, but that key has already (probably) been distributed far and wide with the original SHA-1 binding signature. Even if you update the binding sig, an attacker can still pull the old copy, with the original binding signature, from a keyserver. I think your best bet is to allow your current subkeys to expire or forcibly revoke them and then make new ones with the proper binding signature from day 1. David From dkg at fifthhorseman.net Mon May 4 21:05:47 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 May 2009 15:05:47 -0400 Subject: re-issuing subkey binding signatures with alternate digests In-Reply-To: <8BB89690-87A9-4DC9-B1AF-D40EE9AFBCF7@jabberwocky.com> References: <49FF24A3.9000804@fifthhorseman.net> <8BB89690-87A9-4DC9-B1AF-D40EE9AFBCF7@jabberwocky.com> Message-ID: <49FF3C8B.80701@fifthhorseman.net> On 05/04/2009 02:14 PM, David Shaw wrote: > Let's say your key was originally generated with SHA-1 as the hash for > the subkey binding signature, and you're concerned that an attacker can > do nasty things with that binding signature if and when the SHA-1 break > is extended. You could probably do various pokings about and force that > binding signature to be reissued using SHA-256, but that key has already > (probably) been distributed far and wide with the original SHA-1 binding > signature. Even if you update the binding sig, an attacker can still > pull the old copy, with the original binding signature, from a keyserver. I understand the attack you describe, and realize that what i'm trying to do doesn't defend against it. However, i'm concerned that if we start to explicitly deprecate MD5, then people with MD5-based subkey binding signatures will suddenly find their subkeys not properly associated. If they were able to re-issue the subkey binding signature using a more palatable digest, they'd be able to continue using them even if everyone were to decide that MD5 has the same security properties as sum(1). > I think your best bet is to allow your current subkeys to expire or > forcibly revoke them and then make new ones with the proper binding > signature from day 1. This doesn't address the attack you describe above either, does it? the SHA1 signatures are still out there, published. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon May 4 21:21:46 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 15:21:46 -0400 Subject: re-issuing subkey binding signatures with alternate digests In-Reply-To: <49FF3C8B.80701@fifthhorseman.net> References: <49FF24A3.9000804@fifthhorseman.net> <8BB89690-87A9-4DC9-B1AF-D40EE9AFBCF7@jabberwocky.com> <49FF3C8B.80701@fifthhorseman.net> Message-ID: <3C51C72F-8EEE-40B9-BBE4-B4A5CC71AA8D@jabberwocky.com> On May 4, 2009, at 3:05 PM, Daniel Kahn Gillmor wrote: > On 05/04/2009 02:14 PM, David Shaw wrote: >> Let's say your key was originally generated with SHA-1 as the hash >> for >> the subkey binding signature, and you're concerned that an attacker >> can >> do nasty things with that binding signature if and when the SHA-1 >> break >> is extended. You could probably do various pokings about and force >> that >> binding signature to be reissued using SHA-256, but that key has >> already >> (probably) been distributed far and wide with the original SHA-1 >> binding >> signature. Even if you update the binding sig, an attacker can still >> pull the old copy, with the original binding signature, from a >> keyserver. > > I understand the attack you describe, and realize that what i'm trying > to do doesn't defend against it. However, i'm concerned that if we > start to explicitly deprecate MD5, then people with MD5-based subkey > binding signatures will suddenly find their subkeys not properly > associated. If they were able to re-issue the subkey binding > signature > using a more palatable digest, they'd be able to continue using them > even if everyone were to decide that MD5 has the same security > properties as sum(1). Are there many subkey binding signatures using MD5? Talking about subkeys at all means we're talking about something closer to OpenPGP, which implies SHA-1 to me. >> I think your best bet is to allow your current subkeys to expire or >> forcibly revoke them and then make new ones with the proper binding >> signature from day 1. > > This doesn't address the attack you describe above either, does it? > the > SHA1 signatures are still out there, published. It really depends on the exact details of the attack (I used the "do nasty things with" attack, which isn't terribly specific!) The logic I'm using is: if we're nervous enough about the binding signature hash that we want to reissue it, we aren't actually changing anything by just reissuing the signature. The attacker can just get a copy of the old key and the old signature from any handy keyserver. If, however, we issue a brand new binding sig, on a brand new subkey, then we are changing something. The attacker may be able to attack the old key, but they can't (presumably) attack the new one. Basically, it comes down the attacker being able to attack both the old and new setup, or being only able to attack the old setup. The details, as always, depend on the attack. What attack are you concerned about? David From dkg at fifthhorseman.net Tue May 5 00:52:37 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 May 2009 18:52:37 -0400 Subject: re-issuing subkey binding signatures with alternate digests In-Reply-To: <3C51C72F-8EEE-40B9-BBE4-B4A5CC71AA8D@jabberwocky.com> References: <49FF24A3.9000804@fifthhorseman.net> <8BB89690-87A9-4DC9-B1AF-D40EE9AFBCF7@jabberwocky.com> <49FF3C8B.80701@fifthhorseman.net> <3C51C72F-8EEE-40B9-BBE4-B4A5CC71AA8D@jabberwocky.com> Message-ID: <49FF71B5.1070404@fifthhorseman.net> On 05/04/2009 03:21 PM, David Shaw wrote: > Are there many subkey binding signatures using MD5? Talking about > subkeys at all means we're talking about something closer to OpenPGP, > which implies SHA-1 to me. I have no idea how many there are, actually. But if it makes more sense, imagine planning against the SHA-1 weaknesses instead, a few years down the road. As people start to jump ship from SHA-1 by explicitly distrusting all signatures made under that hash, your old SHA-1 subkey binding will become suspect, even if your key doesn't need to be revoked. >> This doesn't address the attack you describe above either, does it? the >> SHA1 signatures are still out there, published. > > It really depends on the exact details of the attack (I used the "do > nasty things with" attack, which isn't terribly specific!) The logic > I'm using is: if we're nervous enough about the binding signature hash > that we want to reissue it, we aren't actually changing anything by just > reissuing the signature. I'm not nervous about people doing bad things with the signature -- i recognize that if that becomes possible by a digest breakdown, that signature would be rendered useless *whether or not* your specific signature has actually been compromised. Why? Because people have no reason to trust signatures made over compromised hashes. Re-issuing the signature over a stronger hash should make the subkey acceptable to people who have already decided that the older hash is unacceptable. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From jmoore3rd at bellsouth.net Tue May 5 01:40:05 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 04 May 2009 19:40:05 -0400 Subject: Changing GPG's default key type In-Reply-To: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> References: <23EB3AFB-ED76-405E-AFE9-D342ED781EDE@jabberwocky.com> Message-ID: <49FF7CD5.2030302@bellsouth.net> David Shaw wrote: > Currently, GPG's default key type, the one that is recommended to all > new users, is a DSA primary key (1024 bits - not "DSA2") with an Elgamal > subkey. We are currently thinking about changing the default primary to > a 2048-bit RSA key. Do It, Commit It & make the restless natives Happy. ;) JOHN ;) Timestamp: Monday 04 May 2009, 19:39 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue May 5 04:18:39 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 May 2009 22:18:39 -0400 Subject: re-issuing subkey binding signatures with alternate digests In-Reply-To: <49FF71B5.1070404@fifthhorseman.net> References: <49FF24A3.9000804@fifthhorseman.net> <8BB89690-87A9-4DC9-B1AF-D40EE9AFBCF7@jabberwocky.com> <49FF3C8B.80701@fifthhorseman.net> <3C51C72F-8EEE-40B9-BBE4-B4A5CC71AA8D@jabberwocky.com> <49FF71B5.1070404@fifthhorseman.net> Message-ID: On May 4, 2009, at 6:52 PM, Daniel Kahn Gillmor wrote: > On 05/04/2009 03:21 PM, David Shaw wrote: >> Are there many subkey binding signatures using MD5? Talking about >> subkeys at all means we're talking about something closer to OpenPGP, >> which implies SHA-1 to me. > > I have no idea how many there are, actually. But if it makes more > sense, imagine planning against the SHA-1 weaknesses instead, a few > years down the road. As people start to jump ship from SHA-1 by > explicitly distrusting all signatures made under that hash, your old > SHA-1 subkey binding will become suspect, even if your key doesn't > need > to be revoked. There are currently no means to do this with GPG (or other OpenPGP programs, so far as I know). The generally accepted way to deal with this sort of problem is to make a new subkey. After all, you would have to re-distribute your key to give everyone the new binding signature anyway, so you may as well distribute a new subkey. Subkeys are very cheap. David From dkg at fifthhorseman.net Tue May 5 05:26:34 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 May 2009 23:26:34 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <87ab5tthky.fsf@wheatstone.g10code.de> <49FEF8F2.4090703@fifthhorseman.net> Message-ID: <49FFB1EA.30000@fifthhorseman.net> On 05/04/2009 10:46 AM, David Shaw wrote: > Either one is fine for the purpose of this test. The goal is just to > temporarily break MD5 to see what happens. Almost any return code will > do that. OK, i'll make that change. > --disable-digest-algo, if implemented the same way as > --disable-cipher-algo, implies that the hash won't exist at all for that > run. That means it won't be present even for things like --print-md. > Is that the intention here? Hrm. i've been considering Daniel Nagy's recent observation on ietf-openpgp [0] that some uses of a digest algorithm within OpenPGP (self-signatures, in particular) actually only rely on hash function one-wayness, not collision-resistance. It could be useful (though quite possibly "too configurable") to be able to reject the use of a given digest under circumstances where collision-resistance is needed (data signatures and non-self certifications, for example), while permitting it under circumstances where only one-wayness is needed (self-signatures). I have no idea how to communicate this idea in anything resembling a sane UI or configuration file that would be intelligible to normal users, though. --dkg [0] http://www.imc.org/ietf-openpgp/mail-archive/msg33252.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue May 5 20:07:30 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 May 2009 20:07:30 +0200 Subject: [svn] gpgme - r1365 - in trunk: . src In-Reply-To: (svn author marcus's message of "Tue, 05 May 2009 19:03:34 +0200") References: Message-ID: <87y6tb77a5.fsf@wheatstone.g10code.de> On Tue, 5 May 2009 19:03, cvs at cvs.gnupg.org said: > 2009-05-05 Marcus Brinkmann > > * configure.ac: Add infrastructure for compile time check of > _FILE_OFFSET_BITS. Cool. That should catch one of the most common usage errors. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Tue May 5 20:50:42 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 May 2009 14:50:42 -0400 Subject: un-trusting MD5 in gpg [was: Re: removing SHA1 from digest preference list] In-Reply-To: <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> Message-ID: <4A008A82.5030505@fifthhorseman.net> On 05/03/2009 11:11 PM, David Shaw wrote: > On May 3, 2009, at 10:44 PM, David Shaw wrote: >> >> Try this patch (against the 1.4 branch): > > Better patch: I ended up patching gnupg2 (i'm running debian, and have gpg1 and gpg2 installed side by side). The patch i ultimately used was: --- gnupg2-2.0.11.orig/g10/sig-check.c +++ gnupg2-2.0.11/g10/sig-check.c @@ -66,6 +66,9 @@ PKT_public_key *pk = xmalloc_clear( sizeof *pk ); int rc=0; + if(sig->digest_algo==DIGEST_ALGO_MD5) + return G10ERR_DIGEST_ALGO; + if ( (rc=openpgp_md_test_algo(sig->digest_algo)) ) ; /* We don't have this digest. */ else if ((rc=openpgp_pk_test_algo(sig->pubkey_algo))) @@ -529,6 +532,9 @@ sig = node->pkt->pkt.signature; algo = sig->digest_algo; + if(algo==DIGEST_ALGO_MD5) + return G10ERR_DIGEST_ALGO; + /* Check whether we have cached the result of a previous signature check. Note that we may no longer have the pubkey or hash needed to verify a sig, but can still use the cached value. A And it seems to work as expected. That is, i can still use "gpg2 --print-md md5", but when looking at certifications rejects signatures made with md5 like this: sig% 6241B82D 2000-10-05 [Invalid digest algorithm] And when i test an inline signature over MD5, i see the following difference in behavior (gpg is not modified, gpg2 is): > 0 dkg at pip:/tmp/cdtemp.RD4NL4$ gpg --verify test.asc > gpg: Signature made Tue 05 May 2009 02:31:43 PM EDT using RSA key ID D21739E9 > gpg: Good signature from "Daniel Kahn Gillmor " [ultimate] > gpg: aka "Daniel Kahn Gillmor " [ultimate] > gpg: aka "Daniel Kahn Gillmor " [ultimate] > gpg: aka "Daniel Kahn Gillmor " [ultimate] > gpg: aka "[jpeg image of size 3515]" [ultimate] > 0 dkg at pip:/tmp/cdtemp.RD4NL4$ gpg2 --verify test.asc > gpg: Signature made Tue 05 May 2009 02:31:43 PM EDT using RSA key ID D21739E9 > gpg: Can't check signature: Invalid digest algorithm > 2 dkg at pip:/tmp/cdtemp.RD4NL4$ So I'll modify gpg1 with a similar patch shortly to see what i can learn from living with this patch in daily use. Longer term: instead of the test patch hardcoding a rejection of MD5 signatures, it'd be preferable to have a configurable list of digests which are untrusted for signatures and/or certifications. Perhaps instead of --disable-digest-algo (which, by analog with cipher and pubkey, would completely remove the digest), we should consider --no-trust-digest-algo to form a list of deprecated digests. the man page might read something like: --trust-digest-algo name --no-trust-digest-algo name Trust (or not) signatures made over a digest algorithm of *name*. Untrusted digests can still be computed in other contexts, but certifications and data signatures made over untrusted digests will be considered invalid. By default, all implemented digest algorithms are trusted. This way, if we later decide to disable trust in MD5 by default, users who really want MD5 could re-enable it with --trust-digest-algo. Any thoughts on this? I'm leery of adding Yet Another Option to gpg, but i think this might be needed. I'd be interested in other proposals too. And last: is there any reason to add an additional error value to cover these semantics (e.g. G10_ERR_INSECURE_DIGEST_ALGO), or is G10_ERR_DIGEST_ALGO sufficient? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue May 5 23:49:19 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 May 2009 17:49:19 -0400 Subject: un-trusting MD5 in gpg [was: Re: removing SHA1 from digest preference list] In-Reply-To: <4A008A82.5030505@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> Message-ID: <4A00B45F.5090106@fifthhorseman.net> On 05/05/2009 02:50 PM, Daniel Kahn Gillmor wrote: > So I'll modify gpg1 with a similar patch shortly to see what i can learn > from living with this patch in daily use. Well, gpg1 appears to behave the same as gpg2 except that where gpg2 says "Invalid digest algorithm", gpg1 says "unknown digest algorithm" I'll report back any problems i find over the next week of running like this. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed May 6 07:38:53 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 01:38:53 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg Message-ID: <4A01226D.4050606@fifthhorseman.net> Hi gpg folks-- In the interest of building a web of trust that is not reliant on SHA-1 sometime in the future, i've posted some initial suggestions in the form of a HOWTO for debian users and developers to my blog: http://www.debian-administration.org/users/dkg/weblog/48 The goal of the piece is to outline a few practical steps that relatively skilled users can take to lay the groundwork for an environment in which we can effectively deprecate SHA1 in the future without cutting everyone off from each other. I've tried to clarify the potential gravity of the situation without sensationalizing it, and i've tried to provide concrete, non-disruptive things for reasonable people to do in the present that will prepare for a smoother transition in the future. The blog post should be aggregated on http://planet.debian.org/ by now, so i'm hoping DDs (who tend to be well-connected in the WoT) will read it. I welcome any feedback, comments, and corrections. Thanks for all your work on this stuff, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed May 6 15:38:06 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 May 2009 15:38:06 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <4A008A82.5030505@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 05 May 2009 14:50:42 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> Message-ID: <87ws8u5p35.fsf@wheatstone.g10code.de> On Tue, 5 May 2009 20:50, dkg at fifthhorseman.net said: > --trust-digest-algo name > --no-trust-digest-algo name > Trust (or not) signatures made over a digest algorithm of *name*. > Untrusted digests can still be computed in other contexts, but > certifications and data signatures made over untrusted digests > will be considered invalid. By default, all implemented digest > algorithms are trusted. This mixes trust with an algorithm, something we never did. With the same reasoning we could say: Don't trust a key with less than 1536 bits. The point here is that we can't take a decision for the signer - he might have valid reasons to use certain parameters which reflects the needs to fulfill a ertain goal. An option --disable-digest-algo better reflects what you want to do: I don't want to check signatures made using algorithm MD5. It is not a matter of trust but a decision by you and only you. This is similar to my procmailrc which sends all mails with HTML in it to the bit bucket: it is my decisions, that I don't want to see such mails. It does not mean that I don't trust the sender; he might have very good reasons to send HTML mail but for technical reasons I reject them. We need to see whether we can use this option name without getting into problems with gpg2. I don't know right now. Another name might be something along the words --ignore-signatures-with. > And last: is there any reason to add an additional error value to cover > these semantics (e.g. G10_ERR_INSECURE_DIGEST_ALGO), or is > G10_ERR_DIGEST_ALGO sufficient? I can imagin adding a few new error codes; we already have: 43 GPG_ERR_WEAK_KEY Weak encryption key and new ones like: GPG_ERR_WEAK_DIGEST_ALGO GPG_ERR_WEAK_CIPHER_ALGO may be useful for further processing; not necessary to be dispalyed to a user but may be displayed as well in cases you describe. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed May 6 15:45:09 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 May 2009 15:45:09 +0200 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A01226D.4050606@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 06 May 2009 01:38:53 -0400") References: <4A01226D.4050606@fifthhorseman.net> Message-ID: <87skji5ore.fsf@wheatstone.g10code.de> Hi, just a short remark on the Debian keys: Using a 4k RSA key for an automated signing keys or for role purposes is not a good idea at all: It makes the user believe that the archive is secure at that level; but that is clearly not the case. As usual one need to look at the weakest link and here we can find a lot of them: A hijacked developers box (Out of 10000 developers there is for sure at least one folk not protecting his box with all required due diligence), a ssh key floating around at several places, the upstream sources, the protection of all the boxes passed while uploading a package and so on. SCNR, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Wed May 6 16:30:37 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 10:30:37 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <87skji5ore.fsf@wheatstone.g10code.de> References: <4A01226D.4050606@fifthhorseman.net> <87skji5ore.fsf@wheatstone.g10code.de> Message-ID: <4A019F0D.3000109@fifthhorseman.net> On 05/06/2009 09:45 AM, Werner Koch wrote: > Using a 4k RSA key for an automated signing keys or for role purposes is > not a good idea at all: It makes the user believe that the archive is > secure at that level; but that is clearly not the case. As usual one > need to look at the weakest link and here we can find a lot of them: A > hijacked developers box (Out of 10000 developers there is for sure at > least one folk not protecting his box with all required due diligence), > a ssh key floating around at several places, the upstream sources, the > protection of all the boxes passed while uploading a package and so on. I agree with your assessment -- the key for automated signing of the debian archive is almost certainly *not* the weakest link in the chain. On the other hand, if the ftp-masters make a probabilistic assessment of the situation and decide that the archive itself is most likely "secure at the level of DSA-768" because of the vulnerabilities you describe, does that mean that they should sign the archive with a DSA-768 key? I think the reason to have the archive signing keys be beefy is so that the archive key *itself* does not end up being the weakest link, or even a tempting point of attack. I agree with you that it might give some users the wrong impression about the security of the archive, but i'm not sure what a better alternative is. Certainly the explicit inclusion of the term "automatic" in the user ID is helpful in getting users to understand the lack of human judgment involved in the creation of the relevant signatures. Do you have any suggestions for what to change? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed May 6 18:14:10 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 12:14:10 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <87ws8u5p35.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> Message-ID: <4A01B752.6000703@fifthhorseman.net> On 05/06/2009 09:38 AM, Werner Koch wrote: > This mixes trust with an algorithm, something we never did. With the > same reasoning we could say: Don't trust a key with less than 1536 bits. > The point here is that we can't take a decision for the signer - he > might have valid reasons to use certain parameters which reflects the > needs to fulfill a ertain goal. I agree that we can't force a decision on the signer, and we can't force a decision on the person interpreting the signature either. This option would be mechanism to let signature-interpreters set policy like "i need to be assured that the validation i'm seeing has a certain level of tamper-resistance". This is why i framed it as "trust", because validating a signature does indeed imply that you trust the algorithms behind that signature. If i send you a message with a signature made over the simple 160-bit checksum of the message (i know this isn't possible in OpenPGP -- it's a hypothetical), you shouldn't trust that signature because you don't trust the algorithm -- it's too easy to generate arbitrary content that will match that signature. And yes, we might also limit trust in keys by key length. Do you really trust a signature made by a 512-bit RSA key? > An option --disable-digest-algo better reflects what you want to do: I > don't want to check signatures made using algorithm MD5. It is not a > matter of trust but a decision by you and only you. It's both, actually. it's a decision by me and only me that i do not trust signatures using certain algorithmic parameters. I can even specify this preference in a digest algorithms subpacket and broadcast it to the world. > We need to see whether we can use this option name without getting into > problems with gpg2. I don't know right now. Another name might be > something along the words --ignore-signatures-with. I think --ignore-signatures-with makes more sense than --disable-digest-algo simply because i can imagine wanting to add SHA1 to this list in a year and a half (for any work with US federal agencies at least), but gnupg wouldn't even be able to calculate standard fingerprints if SHA1 is completely ripped out. > I can imagin adding a few new error codes; we already have: > > 43 GPG_ERR_WEAK_KEY Weak encryption key > > and new ones like: > > GPG_ERR_WEAK_DIGEST_ALGO > GPG_ERR_WEAK_CIPHER_ALGO > > may be useful for further processing; not necessary to be dispalyed to a > user but may be displayed as well in cases you describe. This seems reasonable to me. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed May 6 20:46:41 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 May 2009 20:46:41 +0200 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A019F0D.3000109@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 06 May 2009 10:30:37 -0400") References: <4A01226D.4050606@fifthhorseman.net> <87skji5ore.fsf@wheatstone.g10code.de> <4A019F0D.3000109@fifthhorseman.net> Message-ID: <87eiv25asu.fsf@wheatstone.g10code.de> On Wed, 6 May 2009 16:30, dkg at fifthhorseman.net said: > I agree with you that it might give some users the wrong impression > about the security of the archive, but i'm not sure what a better > alternative is. Certainly the explicit inclusion of the term The common wisdom is to use 2048 bit RSA for valuable keys. > Do you have any suggestions for what to change? Now that it is in use stick to it. I just couldn't resist to tell what I am thinking if I see such a key. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed May 6 20:53:05 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 06 May 2009 20:53:05 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <4A01B752.6000703@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 06 May 2009 12:14:10 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> Message-ID: <87ab5q5ai6.fsf@wheatstone.g10code.de> On Wed, 6 May 2009 18:14, dkg at fifthhorseman.net said: > This is why i framed it as "trust", because validating a signature does > indeed imply that you trust the algorithms behind that signature. If i The term "trust" is too much overloaded in OpenPGP. IT is never clear what you mean by it. The trust in the person of the user, in the way the user manages the key, how diligent he checks a key before signing it. etc. Due to these problems we try to use the terms "validity" and "ownertrust". Adding another meaning (how strong an algorithm is) to the term "trust" is not a good idea I believe. Thus my whole argument is only against the term and not against the concept that you - how shall I say - trust the algorithms. > I think --ignore-signatures-with makes more sense than > --disable-digest-algo simply because i can imagine wanting to add SHA1 > to this list in a year and a half (for any work with US federal agencies > at least), but gnupg wouldn't even be able to calculate standard > fingerprints if SHA1 is completely ripped out. So we only need a cool name for the new option. >> GPG_ERR_WEAK_DIGEST_ALGO >> GPG_ERR_WEAK_CIPHER_ALGO >> >> may be useful for further processing; not necessary to be dispalyed to a >> user but may be displayed as well in cases you describe. > > This seems reasonable to me. Okay. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Wed May 6 21:19:05 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 15:19:05 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <87ab5q5ai6.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> Message-ID: <4A01E2A9.6030704@fifthhorseman.net> On 05/06/2009 02:53 PM, Werner Koch wrote: > The term "trust" is too much overloaded in OpenPGP. IT is never clear > what you mean by it. The trust in the person of the user, in the way > the user manages the key, how diligent he checks a key before signing > it. etc. > > Due to these problems we try to use the terms "validity" and > "ownertrust". Adding another meaning (how strong an algorithm is) to > the term "trust" is not a good idea I believe. Thus my whole argument > is only against the term and not against the concept that you - how > shall I say - trust the algorithms. ah yes, you are quite correct. > So we only need a cool name for the new option. > >>> GPG_ERR_WEAK_DIGEST_ALGO >>> GPG_ERR_WEAK_CIPHER_ALGO >>> >>> may be useful for further processing; not necessary to be dispalyed to a >>> user but may be displayed as well in cases you describe. >> This seems reasonable to me. > > Okay. What about --weak-digest and --weak-cipher? We also need to think about how to adjust the default list in the other direction, which was what my original --no-trust-digest and --trust-digest tried to cover (albeit with a poorly-chosen name). unfortunately --no-weak-digest doesn't make as much sense. What about --acceptable-digest and --no-acceptable-digest? (--unacceptable-digest or --not-acceptable-digest would be better english for the negation, but would break the parallelism with other gpg options). hmm, i don't like any of the suggestions for names so far now :( --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed May 6 21:31:56 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 15:31:56 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <4A01E2A9.6030704@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> Message-ID: <4A01E5AC.6030000@fifthhorseman.net> On 05/06/2009 03:19 PM, Daniel Kahn Gillmor wrote: > What about --weak-digest and --weak-cipher? We also need to think about > how to adjust the default list in the other direction, which was what my > original --no-trust-digest and --trust-digest tried to cover (albeit > with a poorly-chosen name). unfortunately --no-weak-digest doesn't make > as much sense. Hang on, i think i've overthought this. what about just a simple list by analogy with --personal-digest-preferences: --weak-digest-algos A list of names of digest algorithms considered to be weak enough that signatures over these algorithms should be considered invalid. By default, this list is (empty? MD5?). Supply an empty string or the word "none" to accept valid signatures over all digests. For example: --weak-digest-algos MD5 --weak-digest-algos '' --weak-digest-algos 'MD5 SHA1' Any thoughts? Another approach would be to assume that the complement of the digests listed in --personal-digest-preferences is actually this set. This reduces the gpg's already-hairy configuration space, but it also modifies the semantics of --personal-digest-preferences in ways that might cause problems on existing installations. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed May 6 21:31:25 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 6 May 2009 15:31:25 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <87ws8u5p35.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> Message-ID: <2F1F58BE-6C52-482D-BD7B-1170C2C7D68C@jabberwocky.com> On May 6, 2009, at 9:38 AM, Werner Koch wrote: >> And last: is there any reason to add an additional error value to >> cover >> these semantics (e.g. G10_ERR_INSECURE_DIGEST_ALGO), or is >> G10_ERR_DIGEST_ALGO sufficient? > > I can imagin adding a few new error codes; we already have: > > 43 GPG_ERR_WEAK_KEY Weak encryption key > > and new ones like: > > GPG_ERR_WEAK_DIGEST_ALGO > GPG_ERR_WEAK_CIPHER_ALGO > > may be useful for further processing; not necessary to be dispalyed > to a > user but may be displayed as well in cases you describe. I think if we're going to add new error codes for this, I'd rather just say something like GPG_ERR_DISABLED_DIGEST_ALGO and GPG_ERR_DISABLED_CIPHER_ALGO. Calling it "weak" is a value judgement (i.e. weaker than what? too weak for what?) The WEAK_KEY message is a different sort of thing here as "weak key" is a defined term for those ciphers that have weak keys. Simply calling it "disabled" means exactly what it says: the user disabled it. We shouldn't really care why. Also, when the user sees the string that goes along with that error message, that indicates there is a way to disable and enable digest algorithms, so they can understand what happened. David From dshaw at jabberwocky.com Wed May 6 21:42:28 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 6 May 2009 15:42:28 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <4A01E5AC.6030000@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> Message-ID: <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> On May 6, 2009, at 3:31 PM, Daniel Kahn Gillmor wrote: > On 05/06/2009 03:19 PM, Daniel Kahn Gillmor wrote: >> What about --weak-digest and --weak-cipher? We also need to think >> about >> how to adjust the default list in the other direction, which was >> what my >> original --no-trust-digest and --trust-digest tried to cover (albeit >> with a poorly-chosen name). unfortunately --no-weak-digest doesn't >> make >> as much sense. > > Hang on, i think i've overthought this. what about just a simple list > by analogy with --personal-digest-preferences: > > --weak-digest-algos > A list of names of digest algorithms considered to be weak enough > that signatures over these algorithms should be considered invalid. > By default, this list is (empty? MD5?). Supply an empty string or > the word "none" to accept valid signatures over all digests. I like this basic idea (though don't like the name "weak" for reasons I mentioned earlier). The analogy to personal-digest-preferences is a good one: this is the personal-digest-anti-preferences. Instead of the algorithms the user likes and wants to use when possible, these are the algorithms the user dislikes and won't accept. > Any thoughts? Another approach would be to assume that the complement > of the digests listed in --personal-digest-preferences is actually > this > set. This reduces the gpg's already-hairy configuration space, but it > also modifies the semantics of --personal-digest-preferences in ways > that might cause problems on existing installations. We can't really do that because the meaning of personal-xxx-prefs is "I like these best", not "I will only accept these". People tend to do stuff like "personal-digest-prefs sha256" to favor sha-256, which would immediately lock out every other hash. David From dkg at fifthhorseman.net Wed May 6 22:04:59 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 16:04:59 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> Message-ID: <4A01ED6B.9090202@fifthhorseman.net> On 05/06/2009 03:42 PM, David Shaw wrote: > I like this basic idea (though don't like the name "weak" for reasons I > mentioned earlier). The analogy to personal-digest-preferences is a > good one: this is the personal-digest-anti-preferences. Instead of the > algorithms the user likes and wants to use when possible, these are the > algorithms the user dislikes and won't accept. --unacceptable-digest-algos maybe? Your point about "weak" is a good one, i think. i was unaware that WEAK_KEY had a specific technical meaning. Or what if we framed the option the other way: --acceptable-digest-algos (and it would default to the full set)? > We can't really do that because the meaning of personal-xxx-prefs is "I > like these best", not "I will only accept these". People tend to do > stuff like "personal-digest-prefs sha256" to favor sha-256, which would > immediately lock out every other hash. yeah, that's what i meant by "modifies the semantics of --p-d-p" that'd be a Bad Thing. I just wanted to raise the idea, though. If we were designing gpg from scratch today with no installed userbase, i'd push hard to have it work like this, just for the sake of minimizing the configuration space and presenting a simpler interface. Having the two options allows for some weird (and unnecessary) configurations, like: --unacceptable-digest-algos MD5 --personal-digest-preferences MD5 wherein you would only make signatures that you would never believe were valid. The answer of course, is Don't Do This, but it's unfortunate to give the user that much rope. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed May 6 22:23:19 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 6 May 2009 16:23:19 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <4A01ED6B.9090202@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> Message-ID: <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> On May 6, 2009, at 4:04 PM, Daniel Kahn Gillmor wrote: > On 05/06/2009 03:42 PM, David Shaw wrote: >> I like this basic idea (though don't like the name "weak" for >> reasons I >> mentioned earlier). The analogy to personal-digest-preferences is a >> good one: this is the personal-digest-anti-preferences. Instead of >> the >> algorithms the user likes and wants to use when possible, these are >> the >> algorithms the user dislikes and won't accept. > > --unacceptable-digest-algos maybe? Your point about "weak" is a good > one, i think. i was unaware that WEAK_KEY had a specific technical > meaning. Maybe we should name it personal-digest-something. It makes it clear that these are personal settings, pertain to digests, and that this is sort of a parallel function to personal-digest-preferences. What are the antonyms of preferences? personal-digest-dislikes? personal- digest-rejections? personal-digest-disable? > Having the two > options allows for some weird (and unnecessary) configurations, like: > > --unacceptable-digest-algos MD5 --personal-digest-preferences MD5 > > wherein you would only make signatures that you would never believe > were > valid. The answer of course, is Don't Do This, but it's unfortunate > to > give the user that much rope. Hashes are a bit easier, but you can imagine some real problems with a list of unacceptable ciphers. Let's say that we had a user who set "personal-cipher-donotaccept 3des". What could this user do when encrypting to a bunch of recipients whose ciphers do not intersect on anything other than 3des? I guess the best thing to do would be to simply error out. David From dkg at fifthhorseman.net Wed May 6 22:46:31 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 16:46:31 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> Message-ID: <4A01F727.4090304@fifthhorseman.net> On 05/06/2009 04:23 PM, David Shaw wrote: > Maybe we should name it personal-digest-something. It makes it clear > that these are personal settings, pertain to digests, and that this is > sort of a parallel function to personal-digest-preferences. What are > the antonyms of preferences? personal-digest-dislikes? > personal-digest-rejections? personal-digest-disable? I'm not so sure. as currently defined, personal-digest-preferences apply mainly in situations where you are the only person whose preferences can be taken into account (clearsigning a public document, for example) -- there are no recipients to consider, and you are creating the digest yourself. This seems to be what makes them "personal". But instead, we're talking about not *accepting* a particular digest from someone else (or from yourself at an earlier time). Should this blacklist we're creating also govern digests that we sign over? if we say --personal-digest-blacklist, does that mean both that we will never *generate* signatures over the given hash and that we will not accept signatures over the given hash? > Hashes are a bit easier, but you can imagine some real problems with a > list of unacceptable ciphers. Let's say that we had a user who set > "personal-cipher-donotaccept 3des". What could this user do when > encrypting to a bunch of recipients whose ciphers do not intersect on > anything other than 3des? I guess the best thing to do would be to > simply error out. There is always going to be a problem if the sets of user preferences have no intersection, and this covers digests as well as ciphers. Consider the case where alice at example.org indicates digest preferences in her public self-sig that she only accepts signatures over MD5 and SHA1 hashes, but bob at example.net decides that SHA1 and MD5 are unacceptably compromised and he'll never issue signatures over them for fear that his signature will be transferred to another message. bob simply cannot send signed messages to alice in that case. And yes, gpg should probably error out (or recommend refreshing the recipient's keys, etc) if bob says "sign this message which is going to alice" 4880 mandates that all compliant tools must be *capable* of using SHA1, but it can't compel all humans using the tools to happily generate signatures over that (or any other) algorithm. With flexible cipher suites and tools which adequately represent their users intent, it seems likely that there will always exist some intersection of a user with a pathologically archaic toolset and a user with pathologically bleeding-edge demands. The tools need to be able to fail gracefully when they recognize that such an intersection exists. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From tmz at pobox.com Wed May 6 22:30:01 2009 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 6 May 2009 16:30:01 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> References: <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> Message-ID: <20090506203001.GA4437@inocybe.localdomain> David Shaw wrote: > Maybe we should name it personal-digest-something. It makes it > clear that these are personal settings, pertain to digests, and that > this is sort of a parallel function to personal-digest-preferences. > What are the antonyms of preferences? personal-digest-dislikes? > personal-digest-rejections? personal-digest-disable? Something like personal-digest-excludes, p-d-exclusions, or p-d-exceptions come to my mind. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If at first you don't succeed, failure may be your style. -- Demotivators (www.despair.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed May 6 23:31:22 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 06 May 2009 17:31:22 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <20090506203001.GA4437@inocybe.localdomain> References: <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <20090506203001.GA4437@inocybe.localdomain> Message-ID: <4A0201AA.4010805@sixdemonbag.org> Todd Zullinger wrote: > Something like personal-digest-excludes, p-d-exclusions, or > p-d-exceptions come to my mind. personal-digest-refuse MD5 From dshaw at jabberwocky.com Thu May 7 00:04:06 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 6 May 2009 18:04:06 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <4A01F727.4090304@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> Message-ID: On May 6, 2009, at 4:46 PM, Daniel Kahn Gillmor wrote: > On 05/06/2009 04:23 PM, David Shaw wrote: >> Maybe we should name it personal-digest-something. It makes it clear >> that these are personal settings, pertain to digests, and that this >> is >> sort of a parallel function to personal-digest-preferences. What are >> the antonyms of preferences? personal-digest-dislikes? >> personal-digest-rejections? personal-digest-disable? > > I'm not so sure. as currently defined, personal-digest-preferences > apply mainly in situations where you are the only person whose > preferences can be taken into account (clearsigning a public document, > for example) -- there are no recipients to consider, and you are > creating the digest yourself. This seems to be what makes them > "personal". p-d-p is used during all signing operations whether there are recipients or not. The clearsign case has no recipients, but an encrypt+sign does. Say Alice was signing a document and encrypting it to Baker and Charlie. The cipher is chosen by taking the union of Baker and Charlie's cipher preferences and then using Alice's personal- cipher-preferences to pick Alice's favorite choice from the union. The digest is chosen in the same way: take the union of Baker and Charlie's preferences, and then use Alice's personal-digest- preferences to pick Alice's favorite choice from the union. The only thing that is special about picking digests is that some results are impossible and are automatically discarded. Let's say Alice had a 3072-bit DSA key. The answer thus has to be SHA256, SHA384, or SHA512. If the preferences cannot agree on one of these, then it is forced. Either way, though, Baker and Charlie's preferences are consulted first. > But instead, we're talking about not *accepting* a particular digest > from someone else (or from yourself at an earlier time). Should this > blacklist we're creating also govern digests that we sign over? if we > say --personal-digest-blacklist, does that mean both that we will > never > *generate* signatures over the given hash and that we will not accept > signatures over the given hash? Blacklist is pretty good. We could call it "blacklist-digests" (which gives us a name for "blacklist-ciphers" later). It's reasonably clear just from the name. In terms of whether blacklist-digests only rejects incoming signatures or both rejects incoming signatures and refuses to generate a signature as well, I could make a reasonable argument for either side, but I think I lean more towards doing both - rejecting incoming and not generating outgoing. It would be a strange sort of thing if user disliked an algorithm so much that he refused to accept it from somewhere else, but yet still generated it himself. > With flexible cipher > suites and tools which adequately represent their users intent, it > seems > likely that there will always exist some intersection of a user with a > pathologically archaic toolset and a user with pathologically > bleeding-edge demands. The tools need to be able to fail gracefully > when they recognize that such an intersection exists. Up until today, we have relied on the must-implement algorithms to get us out of a conflict like this. This will be a new, and surprising, behavior for GPG. It will need to be off by default. David From dkg at fifthhorseman.net Thu May 7 00:17:11 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 May 2009 18:17:11 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> Message-ID: <4A020C67.40502@fifthhorseman.net> On 05/06/2009 06:04 PM, David Shaw wrote: > The cipher is chosen by taking the union of Baker and > Charlie's cipher preferences and then using Alice's > personal-cipher-preferences to pick Alice's favorite choice from the > union. Is it really the union and not the intersection? It seems that choosing from the union could leave either Baker or Charlie with an unacceptable choice. > Blacklist is pretty good. We could call it "blacklist-digests" (which > gives us a name for "blacklist-ciphers" later). It's reasonably clear > just from the name. works for me. > In terms of whether blacklist-digests only rejects incoming signatures > or both rejects incoming signatures and refuses to generate a signature > as well, I could make a reasonable argument for either side, but I think > I lean more towards doing both - rejecting incoming and not generating > outgoing. It would be a strange sort of thing if user disliked an > algorithm so much that he refused to accept it from somewhere else, but > yet still generated it himself. i lean the same way myself, toward having it cover both directions. > Up until today, we have relied on the must-implement algorithms to get > us out of a conflict like this. This will be a new, and surprising, > behavior for GPG. It will need to be off by default. "off by default" just means the "must-implement algorithms" are not included in the blacklist by default, right? or do you envision some additional switch needed in order to say "yes, i really want to put the must-implement algorithm in the blacklist"? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu May 7 01:16:37 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 6 May 2009 19:16:37 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <4A020C67.40502@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <4A020C67.40502@fifthhorseman.net> Message-ID: <155805C0-AC8F-40CB-A462-B78B59E68E97@jabberwocky.com> On May 6, 2009, at 6:17 PM, Daniel Kahn Gillmor wrote: > On 05/06/2009 06:04 PM, David Shaw wrote: >> The cipher is chosen by taking the union of Baker and >> Charlie's cipher preferences and then using Alice's >> personal-cipher-preferences to pick Alice's favorite choice from the >> union. > > Is it really the union and not the intersection? It seems that > choosing > from the union could leave either Baker or Charlie with an > unacceptable > choice. Oops, yes, intersection! Fingers not behaving today. >> Up until today, we have relied on the must-implement algorithms to >> get >> us out of a conflict like this. This will be a new, and surprising, >> behavior for GPG. It will need to be off by default. > > "off by default" just means the "must-implement algorithms" are not > included in the blacklist by default, right? or do you envision some > additional switch needed in order to say "yes, i really want to put > the > must-implement algorithm in the blacklist"? Off by default just means that the blacklist is empty by default. If a user wants to blacklist something, whether that something is optional or must-implement, they need to explicitly put it in there. David From wk at gnupg.org Thu May 7 10:53:07 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 10:53:07 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <2F1F58BE-6C52-482D-BD7B-1170C2C7D68C@jabberwocky.com> (David Shaw's message of "Wed, 6 May 2009 15:31:25 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <2F1F58BE-6C52-482D-BD7B-1170C2C7D68C@jabberwocky.com> Message-ID: <87d4al47m4.fsf@wheatstone.g10code.de> On Wed, 6 May 2009 21:31, dshaw at jabberwocky.com said: > GPG_ERR_DISABLED_CIPHER_ALGO. Calling it "weak" is a value judgement > (i.e. weaker than what? too weak for what?) The WEAK_KEY message is Right. I came to the same conclusion this morning. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu May 7 10:57:32 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 10:57:32 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: (David Shaw's message of "Wed, 6 May 2009 18:04:06 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> Message-ID: <878wl947er.fsf@wheatstone.g10code.de> On Thu, 7 May 2009 00:04, dshaw at jabberwocky.com said: > Blacklist is pretty good. We could call it "blacklist-digests" (which > gives us a name for "blacklist-ciphers" later). It's reasonably clear > just from the name. I agree. That term is different from disabled and may be used with different semantics in other tools. I would prefer --blacklist-digest-algo NAME_or_NUMBER The reason is that we do not need a specific order as with personal-digest-preferences. It makes implementation (cf. gpgconf) easier and better matches other options related to algorithms. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Thu May 7 16:37:47 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 10:37:47 -0400 Subject: blacklisting MD5 in gpg [was: Re: un-trusting MD5 in gpg] In-Reply-To: <878wl947er.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> Message-ID: <4A02F23B.2080400@fifthhorseman.net> On 05/07/2009 04:57 AM, Werner Koch wrote: > On Thu, 7 May 2009 00:04, dshaw at jabberwocky.com said: > > I would prefer > > --blacklist-digest-algo NAME_or_NUMBER > > The reason is that we do not need a specific order as with > personal-digest-preferences. It makes implementation (cf. gpgconf) > easier and better matches other options related to algorithms. So if gpg eventually decides to blacklist MD5 by default, and a user throws caution to the winds and decides that they simply must rely on (or create) signatures over MD5, they'd do: --no-blacklist-digest-algo MD5 is that right? Should gpg --version somehow indicate algorithms which it knows about but which are blacklisted in the current configuration? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu May 7 16:40:36 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 10:40:36 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <87d4al47m4.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <2F1F58BE-6C52-482D-BD7B-1170C2C7D68C@jabberwocky.com> <87d4al47m4.fsf@wheatstone.g10code.de> Message-ID: <4A02F2E4.70901@fifthhorseman.net> On 05/07/2009 04:53 AM, Werner Koch wrote: > On Wed, 6 May 2009 21:31, dshaw at jabberwocky.com said: > >> GPG_ERR_DISABLED_CIPHER_ALGO. Calling it "weak" is a value judgement >> (i.e. weaker than what? too weak for what?) The WEAK_KEY message is > > Right. I came to the same conclusion this morning. Y'all have convinced me that "weak" is a bad term here now. Maybe gpg should use an error term that points to the option in question? What about GPG_ERR_BLACKLISTED_DIGEST_ALGO ? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu May 7 17:12:45 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 11:12:45 -0400 Subject: blacklisting MD5 in gpg [was: Re: un-trusting MD5 in gpg] In-Reply-To: <4A02F23B.2080400@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> Message-ID: On May 7, 2009, at 10:37 AM, Daniel Kahn Gillmor wrote: > On 05/07/2009 04:57 AM, Werner Koch wrote: >> On Thu, 7 May 2009 00:04, dshaw at jabberwocky.com said: >> >> I would prefer >> >> --blacklist-digest-algo NAME_or_NUMBER >> >> The reason is that we do not need a specific order as with >> personal-digest-preferences. It makes implementation (cf. gpgconf) >> easier and better matches other options related to algorithms. > > So if gpg eventually decides to blacklist MD5 by default, and a user > throws caution to the winds and decides that they simply must rely on > (or create) signatures over MD5, they'd do: > > --no-blacklist-digest-algo MD5 > > is that right? Sounds good. > Should gpg --version somehow indicate algorithms which it knows about > but which are blacklisted in the current configuration? That's a good idea. Maybe putting it in brackets or something like "[MD5]" to indicate that it exists, but isn't being used. David From dshaw at jabberwocky.com Thu May 7 17:34:22 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 11:34:22 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <878wl947er.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> Message-ID: <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> On May 7, 2009, at 4:57 AM, Werner Koch wrote: > On Thu, 7 May 2009 00:04, dshaw at jabberwocky.com said: > >> Blacklist is pretty good. We could call it "blacklist- >> digests" (which >> gives us a name for "blacklist-ciphers" later). It's reasonably >> clear >> just from the name. > > I agree. That term is different from disabled and may be used with > different semantics in other tools. > > I would prefer > > --blacklist-digest-algo NAME_or_NUMBER > > The reason is that we do not need a specific order as with > personal-digest-preferences. It makes implementation (cf. gpgconf) > easier and better matches other options related to algorithms. Sounds good to me. So, thus far, the plan sounds like: --blacklist-digest-algo (name or number) --no-blacklist-digest-algo (name or number) Repeating the blacklist-digest-algo option can be done to add more than one algorithm to the blacklist. no-blacklist-digest-algo can be used to remove something from the list. Whoever gets in last (add to the list or remove from the list) wins. A blacklisted digest will cause signature verification to fail with an appropriate error message along the lines of "digest algorithm is blacklisted" (internally, GPG_ERR_BLACKLISTED_DIGEST or the like). A key certification created with a blacklisted digest will not be part of the web of trust. A blacklisted digest will also not be usable when creating a signature/ certification, with the same sort of error returned. This does not affect the use of the digest in things like --print-md. gpg --version will flag blacklisted algorithms by putting them in [brackets]. David From dkg at fifthhorseman.net Thu May 7 18:11:10 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 12:11:10 -0400 Subject: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] In-Reply-To: <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> Message-ID: <4A03081E.10700@fifthhorseman.net> On 05/07/2009 11:34 AM, David Shaw wrote: > So, thus far, the plan sounds like: > > --blacklist-digest-algo (name or number) > --no-blacklist-digest-algo (name or number) > > Repeating the blacklist-digest-algo option can be done to add more than > one algorithm to the blacklist. no-blacklist-digest-algo can be used to > remove something from the list. Whoever gets in last (add to the list > or remove from the list) wins. > > A blacklisted digest will cause signature verification to fail with an > appropriate error message along the lines of "digest algorithm is > blacklisted" (internally, GPG_ERR_BLACKLISTED_DIGEST or the like). > > A key certification created with a blacklisted digest will not be part > of the web of trust. > > A blacklisted digest will also not be usable when creating a > signature/certification, with the same sort of error returned. > > This does not affect the use of the digest in things like --print-md. > > gpg --version will flag blacklisted algorithms by putting them in > [brackets]. This is a good summary, and sounds like a very useful feature proposal. While we're defining this, do we want to also define --blacklist-cipher-algo ? Semantically, i imagine that adding a cipher to the blacklist would result in the following: * nothing would ever be encrypted over the blacklisted cipher * when decrypting data encrypted by a blacklisted cipher, gpg would emit a warning. If blacklist-cipher-algo is at all controversial, i'm fine with tabling the discussion on it. I don't want it to divert attention from the blacklist-digest-algo proposal, which seems a higher priority to me. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu May 7 18:36:58 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 18:36:58 +0200 Subject: blacklisting MD5 in gpg In-Reply-To: (David Shaw's message of "Thu, 7 May 2009 11:12:45 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> Message-ID: <87ab5o98et.fsf@wheatstone.g10code.de> On Thu, 7 May 2009 17:12, dshaw at jabberwocky.com said: >> Should gpg --version somehow indicate algorithms which it knows about >> but which are blacklisted in the current configuration? > > That's a good idea. Maybe putting it in brackets or something like > "[MD5]" to indicate that it exists, but isn't being used. Unfortunately this is hard to implement because --version is processed by the option parser internally and I doubt that it makes sense to change this to display more information. --version displays the build in algorithms; thus even the option --disable-cipher-algo has no effect. The prober way to get the current configuration is to read gpg.conf or to use gpgconf along with a GUI tool. There are just to many setting in gpg to show them all. We would need to add extra code to show them and we will for sure encounter bugs in that the option setting is not displayed properly. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu May 7 18:41:17 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 18:41:17 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> (David Shaw's message of "Thu, 7 May 2009 11:34:22 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> Message-ID: <8763gc987m.fsf@wheatstone.g10code.de> On Thu, 7 May 2009 17:34, dshaw at jabberwocky.com said: > --blacklist-digest-algo (name or number) > --no-blacklist-digest-algo (name or number) > > Repeating the blacklist-digest-algo option can be done to add more > than one algorithm to the blacklist. no-blacklist-digest-algo can be > used to remove something from the list. Whoever gets in last (add to > the list or remove from the list) wins. Okay. > A blacklisted digest will cause signature verification to fail with an > appropriate error message along the lines of "digest algorithm is > blacklisted" (internally, GPG_ERR_BLACKLISTED_DIGEST or the like). The name of the erro code is too specific. GPG_ERR_DISABLED_DIGEST is better; if you like the error message may say "...disabled or blacklisted". > A key certification created with a blacklisted digest will not be part > of the web of trust. > > A blacklisted digest will also not be usable when creating a signature/ > certification, with the same sort of error returned. > > This does not affect the use of the digest in things like --print-md. Okay. > gpg --version will flag blacklisted algorithms by putting them in > [brackets]. Not okay, see my other mail. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Thu May 7 19:09:41 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 13:09:41 -0400 Subject: blacklisting MD5 in gpg In-Reply-To: <87ab5o98et.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> <87ab5o98et.fsf@wheatstone.g10code.de> Message-ID: <4A0315D5.1030309@fifthhorseman.net> On 05/07/2009 12:36 PM, Werner Koch wrote: > Unfortunately this is hard to implement because --version is processed > by the option parser internally and I doubt that it makes sense to > change this to display more information. --version displays the build > in algorithms; thus even the option --disable-cipher-algo has no effect. really? it works for me on a debian testing system: >> 0 dkg at pip:~$ diff -u <(gpg --version) <(gpg --disable-cipher-algo CAST5 --version) >> --- /dev/fd/63 2009-05-07 13:00:29.744655397 -0400 >> +++ /dev/fd/62 2009-05-07 13:00:29.752652274 -0400 >> @@ -7,6 +7,6 @@ >> Home: ~/.gnupg >> Supported algorithms: >> Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA >> -Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH >> +Cipher: 3DES, BLOWFISH, AES, AES192, AES256, TWOFISH >> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 >> Compression: Uncompressed, ZIP, ZLIB, BZIP2 >> 1 dkg at pip:~$ diff -u <(gpg2 --version) <(gpg2 --disable-cipher-algo CAST5 --version) >> --- /dev/fd/63 2009-05-07 13:01:00.184650141 -0400 >> +++ /dev/fd/62 2009-05-07 13:01:00.184650141 -0400 >> @@ -8,6 +8,6 @@ >> Home: ~/.gnupg >> Supported algorithms: >> Pubkey: RSA, ELG, DSA >> -Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH >> +Cipher: 3DES, BLOWFISH, AES, AES192, AES256, TWOFISH >> Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 >> Compression: Uncompressed, ZIP, ZLIB, BZIP2 >> 1 dkg at pip:~$ it seems to work if i set it in gpg.conf too. > The prober way to get the current configuration is to read gpg.conf or > to use gpgconf along with a GUI tool. There are just to many setting in > gpg to show them all. We would need to add extra code to show them and > we will for sure encounter bugs in that the option setting is not > displayed properly. what about including it in the output of --list-config? (personally, i'd like to see it in both --list-config and --version) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu May 7 19:14:06 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 13:14:06 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <8763gc987m.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <8763gc987m.fsf@wheatstone.g10code.de> Message-ID: <4A0316DE.1080600@fifthhorseman.net> On 05/07/2009 12:41 PM, Werner Koch wrote: > On Thu, 7 May 2009 17:34, dshaw at jabberwocky.com said: >> A blacklisted digest will cause signature verification to fail with an >> appropriate error message along the lines of "digest algorithm is >> blacklisted" (internally, GPG_ERR_BLACKLISTED_DIGEST or the like). > > The name of the erro code is too specific. GPG_ERR_DISABLED_DIGEST is > better; if you like the error message may say "...disabled or blacklisted". Can you explain what the problem is with having a more-specific error code? We're talking about introducing new semantics in gpg already. Why not have an error code that specifically refers to those semantics? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From jmoore3rd at bellsouth.net Thu May 7 19:15:25 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 07 May 2009 13:15:25 -0400 Subject: un-trusting MD5 in gpg In-Reply-To: <8763gc987m.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <8763gc987m.fsf@wheatstone.g10code.de> Message-ID: <4A03172D.1020208@bellsouth.net> Werner Koch wrote: > The name of the erro code is too specific. GPG_ERR_DISABLED_DIGEST is > better; if you like the error message may say "...disabled or blacklisted". I am very interested in these discussions but they have brought to mind a Question: How many instances of --verbose will need to be called for the 'blacklisted' messages to usefully appear? 1, 2 or all 3? I bring this up specifically because in the Past I discovered that calling 3 instances of --verbose for maximum 'information' can cause the View Photo ID option within Enigmail to fail. Certainly not the end of the World but one of the 'rabbit trails' My mind constantly considers. JOHN :-D Timestamp: Thursday 07 May 2009, 13:15 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu May 7 19:25:07 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 13:25:07 -0400 Subject: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] In-Reply-To: <4A03081E.10700@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> Message-ID: <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> On May 7, 2009, at 12:11 PM, Daniel Kahn Gillmor wrote: > While we're defining this, do we want to also define > --blacklist-cipher-algo ? Semantically, i imagine that adding a > cipher > to the blacklist would result in the following: > > * nothing would ever be encrypted over the blacklisted cipher > * when decrypting data encrypted by a blacklisted cipher, gpg would > emit a warning. We effectively have this now. If you take the cipher out of both your on-key preferences and your personal-cipher-preferences, then other people will not use it when encrypting to you, and you will not use it when encrypting to other people. GPG will even print a warning if someone uses it to encrypt to you ("WARNING: cipher algorithm such-and- such not found in recipient preferences"). The only difference I see between this and a possible blacklist-cipher- algo is that presumably you could blacklist 3DES, which you can't remove from preferences. David From dshaw at jabberwocky.com Thu May 7 19:29:48 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 13:29:48 -0400 Subject: blacklisting MD5 in gpg In-Reply-To: <4A0315D5.1030309@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> <87ab5o98et.fsf@wheatstone.g10code.de> <4A0315D5.1030309@fifthhorseman.net> Message-ID: <5713D0E6-E0C6-421E-9337-F2FE0CCCAFF1@jabberwocky.com> On May 7, 2009, at 1:09 PM, Daniel Kahn Gillmor wrote: > >> The prober way to get the current configuration is to read gpg.conf >> or >> to use gpgconf along with a GUI tool. There are just to many >> setting in >> gpg to show them all. We would need to add extra code to show them >> and >> we will for sure encounter bugs in that the option setting is not >> displayed properly. > > what about including it in the output of --list-config? (personally, > i'd like to see it in both --list-config and --version) That's what I was thinking. GUI tools should never be parsing -- version. That's for human beings. David From wk at gnupg.org Thu May 7 19:28:27 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 19:28:27 +0200 Subject: blacklisting MD5 in gpg In-Reply-To: <4A0315D5.1030309@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2009 13:09:41 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> <87ab5o98et.fsf@wheatstone.g10code.de> <4A0315D5.1030309@fifthhorseman.net> Message-ID: <87skjg7rgk.fsf@wheatstone.g10code.de> On Thu, 7 May 2009 19:09, dkg at fifthhorseman.net said: > really? it works for me on a debian testing system: Ooops. I don't know my own code anymore :-(. Before parsing --version on the command line all the other options are processed as usual and then the algorithm list building function can make use of them. I thought that version would be processed by the first pass of the option parser which looks for things like --option and --homedir before parsing the option file. I missed that I once ... Wed Jun 10 07:39:41 1998 Werner Koch,mobil,,, (wk at tobold) * fileutil.c (compare_filenames): New. * argparse.c (arg_parse): New flag bit 6 to ignore --version ... introduced a flag to suppress exactly that. Please forget about my comment. We can for sure put brackets around blacklisted algos. > what about including it in the output of --list-config? (personally, > i'd like to see it in both --list-config and --version) Can be done. However, gpgconf is the modern tool to ask for configuration settings. We have just not implemented the more exotic options like --disable-algo and --personal-foo-prefs. The latter seems to be important, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu May 7 19:31:38 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 19:31:38 +0200 Subject: --blacklist-digest-algo plans In-Reply-To: <4A03081E.10700@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2009 12:11:10 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> Message-ID: <87my9o7rb9.fsf@wheatstone.g10code.de> On Thu, 7 May 2009 18:11, dkg at fifthhorseman.net said: > While we're defining this, do we want to also define > --blacklist-cipher-algo ? Semantically, i imagine that adding a cipher > to the blacklist would result in the following: > > * nothing would ever be encrypted over the blacklisted cipher That can be done with --disable-cipher-algo. > * when decrypting data encrypted by a blacklisted cipher, gpg would > emit a warning. That might make sense. However, I don't see a use case. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu May 7 19:36:58 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 May 2009 19:36:58 +0200 Subject: un-trusting MD5 in gpg In-Reply-To: <4A0316DE.1080600@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 07 May 2009 13:14:06 -0400") References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <8763gc987m.fsf@wheatstone.g10code.de> <4A0316DE.1080600@fifthhorseman.net> Message-ID: <87iqkc7r2d.fsf@wheatstone.g10code.de> On Thu, 7 May 2009 19:14, dkg at fifthhorseman.net said: > Can you explain what the problem is with having a more-specific error > code? We're talking about introducing new semantics in gpg already. > Why not have an error code that specifically refers to those semantics? There are already too many different error codes out of histroical reasons. Over the time I learned that many orf them are not very usefule, whereas others are too broad. These error codes are not only for displaying someting to a user but mainly used as a small-bandwidth notification system. GnuPG acts on certain error codes and I can't see how it should behave different on a disabled and a blacklisted also. In fact I am not sure whether we need them at all, we can display a custom message to the user (or via --status-fd) and internally use the error code for unknown algorithm. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dkg at fifthhorseman.net Thu May 7 19:53:51 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 13:53:51 -0400 Subject: blacklist-cipher-algo [Re: --blacklist-digest-algo plans] In-Reply-To: <87my9o7rb9.fsf@wheatstone.g10code.de> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> <87my9o7rb9.fsf@wheatstone.g10code.de> Message-ID: <4A03202F.6060805@fifthhorseman.net> On 05/07/2009 01:31 PM, Werner Koch wrote: > On Thu, 7 May 2009 18:11, dkg at fifthhorseman.net said: > >> While we're defining this, do we want to also define >> --blacklist-cipher-algo ? Semantically, i imagine that adding a cipher >> to the blacklist would result in the following: >> >> * nothing would ever be encrypted over the blacklisted cipher > > That can be done with --disable-cipher-algo. --disable-cipher-algo also has the effect that no decryption can be done with that algorithm, though. anyway, it's clear that blacklist-cipher-algo is at least marginally controversial. So i'll drop it for now so that we can concentrate on blacklist-digest-algo. thanks for the feedback, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu May 7 20:03:59 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 14:03:59 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A01226D.4050606@fifthhorseman.net> References: <4A01226D.4050606@fifthhorseman.net> Message-ID: <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> On May 6, 2009, at 1:38 AM, Daniel Kahn Gillmor wrote: > Hi gpg folks-- > > In the interest of building a web of trust that is not reliant on > SHA-1 > sometime in the future, i've posted some initial suggestions in the > form > of a HOWTO for debian users and developers to my blog: > > http://www.debian-administration.org/users/dkg/weblog/48 > > The goal of the piece is to outline a few practical steps that > relatively skilled users can take to lay the groundwork for an > environment in which we can effectively deprecate SHA1 in the future > without cutting everyone off from each other. I think you did a good job on this. I have one comment, in regards to step 5 in your migration plan: >> 5. (day 0 through day 90) Review the set of public certifications >> you've made ("keys you've signed") with your old key. For keys you >> believe to still be active (maybe you want to check with the key >> owner), issue a new certification with your new key. If you get a >> request for new keysignings, use your new key during this period. This one bothers me a bit. I would definitely not want to re-sign a key without - at a minimum - checking with the key owner. For all I know, he's lost the secret key or doesn't use that key any longer. Presumably I did some decent level of checking when I first signed his key, and I need to take care if I don't want to violate that original check when/if I re-sign. Personally, when I switched to SHA-256 a few years ago, I didn't re- issue any signatures. If I happen on the same person at a keysigning event, I'll re-sign of course, but I didn't seek people out to do it. I think it's prudent to move away from SHA-1 (and did), but actually going back and re-making old signatures seems excessive to me. Incidentally, there is a minor technical gotcha in the re-signing plans in general. Neither PGP nor GPG will allow you to re-sign a key you've already signed. You can work around this by deleting the old signature first, then re-signing. GPG also lets you force a re-signing by signing with "--expert", but that's not really appropriate for a published plan like yours (as a general thing, if you have to use --expert to get a regular job done, something is wrong somewhere). David From rjh at sixdemonbag.org Thu May 7 20:05:43 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 07 May 2009 14:05:43 -0400 Subject: blacklisting MD5 in gpg In-Reply-To: <5713D0E6-E0C6-421E-9337-F2FE0CCCAFF1@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> <87ab5o98et.fsf@wheatstone.g10code.de> <4A0315D5.1030309@fifthhorseman.net> <5713D0E6-E0C6-421E-9337-F2FE0CCCAFF1@jabberwocky.com> Message-ID: <4A0322F7.6020209@sixdemonbag.org> David Shaw wrote: > That's what I was thinking. GUI tools should never be parsing > --version. That's for human beings. Perhaps this should be added to the manpage and/or the hacking file, then. It seems probable that many scripts do just this, and if it's a "they should never...", then script authors should have some resource to tell them so. From jmoore3rd at bellsouth.net Thu May 7 20:10:23 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 07 May 2009 14:10:23 -0400 Subject: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] In-Reply-To: <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> Message-ID: <4A03240F.9050109@bellsouth.net> David Shaw wrote: > We effectively have this now. If you take the cipher out of both your > on-key preferences and your personal-cipher-preferences, then other > people will not use it when encrypting to you, and you will not use it > when encrypting to other people. GPG will even print a warning if > someone uses it to encrypt to you ("WARNING: cipher algorithm > such-and-such not found in recipient preferences"). Err..... This presupposes that _all_ Correspondents re-Import/Refresh One's Key with the "re-preferenced" Copy. Good Luck with that. JOHN :-\ Timestamp: Thursday 07 May 2009, 14:09 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu May 7 20:19:05 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 14:19:05 -0400 Subject: blacklisting MD5 in gpg In-Reply-To: <4A0322F7.6020209@sixdemonbag.org> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <4A02F23B.2080400@fifthhorseman.net> <87ab5o98et.fsf@wheatstone.g10code.de> <4A0315D5.1030309@fifthhorseman.net> <5713D0E6-E0C6-421E-9337-F2FE0CCCAFF1@jabberwocky.com> ! <4A0322F7.6020209@sixdemonbag.org> Message-ID: <212AD108-2A25-48AF-84CB-F1D7D22BB7C2@jabberwocky.com> On May 7, 2009, at 2:05 PM, Robert J. Hansen wrote: > David Shaw wrote: >> That's what I was thinking. GUI tools should never be parsing >> --version. That's for human beings. > > Perhaps this should be added to the manpage and/or the hacking file, > then. It seems probable that many scripts do just this, and if it's a > "they should never...", then script authors should have some > resource to > tell them so. There are limits to this sort of thing. Each option that is intended for tools is tagged as such (--list-options, --with-colons, etc). Past a certain point, we're just making the manual hard(er) to read with endless repetitions of don't-use-this-in-scripts. Perhaps a single statement that says the only safe way to use GPG at all for scripts is via --with-colons and friends. David From dshaw at jabberwocky.com Thu May 7 21:28:35 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 15:28:35 -0400 Subject: --blacklist-digest-algo plans [was: Re: un-trusting MD5 in gpg] In-Reply-To: <4A03240F.9050109@bellsouth.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> <4A03240F.9050109@bellsouth.net> Message-ID: <215E92EA-84DA-4D20-AC55-4250F7595096@jabberwocky.com> On May 7, 2009, at 2:10 PM, John W. Moore III wrote: > David Shaw wrote: > >> We effectively have this now. If you take the cipher out of both >> your >> on-key preferences and your personal-cipher-preferences, then other >> people will not use it when encrypting to you, and you will not use >> it >> when encrypting to other people. GPG will even print a warning if >> someone uses it to encrypt to you ("WARNING: cipher algorithm >> such-and-such not found in recipient preferences"). > > Err..... This presupposes that _all_ Correspondents re-Import/Refresh > One's Key with the "re-preferenced" Copy. Good Luck with that. No, it does not change the situation at all. In the "preferences" case, you won't generate a message with the cipher in question. If you get a message with the cipher in question, you will decrypt it but will display a warning. In the "blacklist" case, you still won't generate a message with the cipher in question. And if you get a message with the cipher in question, you will still decrypt it, and will still display a warning. The only difference between the two is that in the "preferences" case, you at least told people not to use the cipher. Sure, they may not have gotten the update, or may choose to ignore you, but even if they do, the effect is the same on your side. David From dkg at fifthhorseman.net Thu May 7 22:57:23 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 16:57:23 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> Message-ID: <4A034B33.8050901@fifthhorseman.net> Hi David, thanks for your feedback. Some comments below: On 05/07/2009 02:03 PM, David Shaw wrote: > I think you did a good job on this.I have one comment, in regards to > step 5 in your migration plan: > >>> 5. (day 0 through day 90) Review the set of public certifications >>> you've made ("keys you've signed") with your old key. For keys you >>> believe to still be active (maybe you want to check with the key >>> owner), issue a new certification with your new key. If you get a >>> request for new keysignings, use your new key during this period. > > This one bothers me a bit. I would definitely not want to re-sign a key > without - at a minimum - checking with the key owner. For all I know, > he's lost the secret key or doesn't use that key any longer. Presumably > I did some decent level of checking when I first signed his key, and I > need to take care if I don't want to violate that original check when/if > I re-sign. I agree that checking with the key owner is more of a requirement than a recommendation before re-issuing the certifications. i've updated the blog post to reflect that change. I welcome public comments on the blog as well. > Personally, when I switched to SHA-256 a few years ago, I didn't > re-issue any signatures. Your key does not indicate a switch to SHA256: 0 dkg at pip:~$ gpg --export --export-options export-minimal 99242560 | \ > gpg --list-packets | grep pref-hash-algos hashed subpkt 21 len 2 (pref-hash-algos: 3 2) 0 dkg at pip:~$ Should i refresh it from somewhere else? > If I happen on the same person at a keysigning > event, I'll re-sign of course, but I didn't seek people out to do it. I > think it's prudent to move away from SHA-1 (and did), but actually going > back and re-making old signatures seems excessive to me. My goal is to make sure that there *is* a reasonable non-SHA1 WoT in the near future, which is why i included that step. If everyone had switched to SHA256 when you did (i wish i had), we'd have such a WoT by now, and we could start actively deprecating SHA-1 instead of just laying groundwork. My thought was that we could get new non-SHA1 certifications out there in the near-term, before there are active attacks(?) that would render review of our previous SHA-1 signatures dubious. > Incidentally, there is a minor technical gotcha in the re-signing plans > in general. Neither PGP nor GPG will allow you to re-sign a key you've > already signed. You can work around this by deleting the old signature > first, then re-signing. Ah, good point. But this is signing with a new key (it's in the context of a key transition). That should be OK, right? > GPG also lets you force a re-signing by signing with "--expert", but > that's not really appropriate for a published plan like yours (as a > general thing, if you have to use --expert to get a regular job done, > something is wrong somewhere). agreed! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu May 7 23:52:22 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 May 2009 17:52:22 -0400 Subject: 3DES special case [Was: Re: --blacklist-digest-algo plans] In-Reply-To: <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> Message-ID: <4A035816.7070002@fifthhorseman.net> On 05/07/2009 01:25 PM, David Shaw wrote: > We effectively have this now. If you take the cipher out of both your > on-key preferences and your personal-cipher-preferences, then other > people will not use it when encrypting to you, and you will not use it > when encrypting to other people. GPG will even print a warning if > someone uses it to encrypt to you ("WARNING: cipher algorithm > such-and-such not found in recipient preferences"). > > The only difference I see between this and a possible > blacklist-cipher-algo is that presumably you could blacklist 3DES, which > you can't remove from preferences. Why not emit a warning if 3DES is not in the preferences either? the RFC says MUST-Implement, not MUST-NOT-Warn. Currently, gpg implements CAST5, but if you --encrypt --cipher-algo CAST5 to someone whose preferences don't list CAST5, you get a warning. And if you --decrypt something over CAST5, and it is not explicitly in your preferences, you get a warning. Why not treat 3DES the same way? sure, we know that RFC-compliant OpenPGP implementations will be able to handle it. But if someone has explicitly stricken it from their preference list, that probably means they'd rather not receive 3DES-encrypted messages. A warning seems reasonable to me. FWIW, i just added "disable-cipher-algo 3DES" to my ~/.gnupg/gpg.conf today to see what happens. i'm aware that this drastic step makes gpg non-RFC-compliant, but it's the closest i can currently come to getting it to represent my actual cipher preferences. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri May 8 01:40:18 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 19:40:18 -0400 Subject: 3DES special case [Was: Re: --blacklist-digest-algo plans] In-Reply-To: <4A035816.7070002@fifthhorseman.net> References: <49FCDAAD.2050000@fifthhorseman.net> <49FD0EE5.50809@bellsouth.net> <49FDCCD0.10300@fifthhorseman.net> <49FE3B77.2040900@fifthhorseman.net> <97A97596-4A0C-442D-A704-0BB2542A2F53@jabberwocky.com> <9ED1F71D-3FDF-409B-8449-9C72CE35F36F@jabberwocky.com> <4A008A82.5030505@fifthhorseman.net> <87ws8u5p35.fsf@wheatstone.g10code.de> <4A01B752.6000703@fifthhorseman.net> <87ab5q5ai6.fsf@wheatstone.g10code.de> <4A01E2A9.6030704@fifthhorseman.net> <4A01E5AC.6030000@fifthhorseman.net> <0F0B05A2-AF71-4CA2-A7B4-A6362FD9E27F@jabberwocky.com> <4A01ED6B.9090202@fifthhorseman.net> <9EED93AE-B8F1-45FB-BC90-55CD2CD91A1A@jabberwocky.com> <4A01F727.4090304@fifthhorseman.net> <878wl947er.fsf@wheatstone.g10code.de> <99D82FC0-03C1-4E8B-AA82-00736CDE84AC@jabberwocky.com> <4A03081E.10700@fifthhorseman.net> <1C797A87-CAC8-4C7A-AF69-20261DD320EB@jabberwocky.com> <4A035816.7070002@fifthhorseman.net> Message-ID: On May 7, 2009, at 5:52 PM, Daniel Kahn Gillmor wrote: > On 05/07/2009 01:25 PM, David Shaw wrote: >> We effectively have this now. If you take the cipher out of both >> your >> on-key preferences and your personal-cipher-preferences, then other >> people will not use it when encrypting to you, and you will not use >> it >> when encrypting to other people. GPG will even print a warning if >> someone uses it to encrypt to you ("WARNING: cipher algorithm >> such-and-such not found in recipient preferences"). >> >> The only difference I see between this and a possible >> blacklist-cipher-algo is that presumably you could blacklist 3DES, >> which >> you can't remove from preferences. > > Why not emit a warning if 3DES is not in the preferences either? the > RFC says MUST-Implement, not MUST-NOT-Warn. The RFC says that you must implement 3DES, and also that 3DES is always in the preferences. If it's not actually there, then the implementation needs to pretend that it is. > Currently, gpg implements CAST5, but if you --encrypt --cipher-algo > CAST5 to someone whose preferences don't list CAST5, you get a > warning. > And if you --decrypt something over CAST5, and it is not explicitly in > your preferences, you get a warning. Yes. Because the protocol was violated. The protocol, by definition, is never violated by using 3DES as 3DES is always in every preference list. It can't be removed, because even if you remove it, the implementation is required to pretend it was there. That said, you don't need to torture the standard to accomplish what you want. If you want to print a warning on 3DES, or SHA-1, or even because it just happens to be Thursday, any implementation can do that without needing to justify it somehow in the standard. Whether it is wise or not is a different question. > Why not treat 3DES the same way? sure, we know that RFC-compliant > OpenPGP implementations will be able to handle it. But if someone has > explicitly stricken it from their preference list, that probably means > they'd rather not receive 3DES-encrypted messages. A warning seems > reasonable to me. I strongly disagree. You can't make such an assumption for the entire OpenPGP community, especially as it warns on something that was completely normal, expected, and good behavior previously. This might make sense if the behavior was no longer expected and good, but that is not the case. Not only has 3DES not been cracked, it's stood up to more attacks than any of the other ciphers in OpenPGP. The main problem with 3DES is that it's really slow. > FWIW, i just added "disable-cipher-algo 3DES" to my ~/.gnupg/gpg.conf > today to see what happens. i'm aware that this drastic step makes gpg > non-RFC-compliant, but it's the closest i can currently come to > getting > it to represent my actual cipher preferences. This is a perfectly fine thing to do. You're sort of aiming a gun at your foot, true, but it's *your* foot and nobody else's. In practice, given somewhat recent OpenPGP implementations, and keys with somewhat recent preferences, I doubt you'll see 3DES used that often. Too many people rank AES higher. David From dshaw at jabberwocky.com Fri May 8 02:07:30 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 May 2009 20:07:30 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A034B33.8050901@fifthhorseman.net> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> Message-ID: <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> On May 7, 2009, at 4:57 PM, Daniel Kahn Gillmor wrote: >> Personally, when I switched to SHA-256 a few years ago, I didn't >> re-issue any signatures. > > Your key does not indicate a switch to SHA256: I meant when I switched to SHA-256 for key signing (i.e. "cert-digest- algo sha256"). I've been meaning to update my preference lists, actually, but I'm waiting for the Camellia draft to be published (it received IESG approval today, so we're getting closer). >> If I happen on the same person at a keysigning >> event, I'll re-sign of course, but I didn't seek people out to do >> it. I >> think it's prudent to move away from SHA-1 (and did), but actually >> going >> back and re-making old signatures seems excessive to me. > > My goal is to make sure that there *is* a reasonable non-SHA1 WoT in > the > near future, which is why i included that step. If everyone had > switched to SHA256 when you did (i wish i had), we'd have such a WoT > by > now, and we could start actively deprecating SHA-1 instead of just > laying groundwork. > > My thought was that we could get new non-SHA1 certifications out > there > in the near-term, before there are active attacks(?) that would render > review of our previous SHA-1 signatures dubious. I don't think that the SHA-1 situation is nearly that dire. What is the attack that you're worried about here? Sure, let's all switch over to something better, but I think that the idea that we have to quickly rebuild the web of trust or that we're somehow in a race against time before someone starts forging signatures is more than a bit excessive. >> Incidentally, there is a minor technical gotcha in the re-signing >> plans >> in general. Neither PGP nor GPG will allow you to re-sign a key >> you've >> already signed. You can work around this by deleting the old >> signature >> first, then re-signing. > > Ah, good point. But this is signing with a new key (it's in the > context > of a key transition). That should be OK, right? With a new key there is no problem. If someone has a RSA or DSA2 key already, though, and simply wants to start issuing SHA-256 signatures instead of SHA-1, they might run into a problem. David From ueno at unixuser.org Fri May 8 11:38:40 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 08 May 2009 18:38:40 +0900 Subject: [PATCH] Caching symmetric encryption passphrase with gpg-agent Message-ID: <87ab5o7x3z.fsf@broken.deisui.org> Hi, The attached is a new patch for caching symmetric encryption passphrase using a S2K salt as a cache key, as I proposed a couple of months ago. I think it now should be ready for use, and hopefully for being integrated into the trunk. One thing I'm wondering--should I add an option to turn on/off such an experimental feature? If so, I'll post the modified version to the list. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg2-cache-symmetric-passphrase.diff Type: text/x-diff Size: 5384 bytes Desc: not available URL: -------------- next part -------------- P.S. Thanks Werner for your neat work related to my previous buggy patch and sorry for late response. Regards, -- Daiki Ueno From patrick at mozilla-enigmail.org Fri May 8 17:01:01 2009 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Fri, 08 May 2009 17:01:01 +0200 Subject: Feature Request: Parseable output if gpg waits for lock Message-ID: <4A04492D.40008@mozilla-enigmail.org> Every now and then some user reports a problem to Enigmail because gpg is hanging for no obvious reason, which then turns out to be gpg waiting for the lock files to be deleted. The problem is that the output of gpg ("gpg: waiting for lock (held by NNNN - probably dead) ...") is on STDERR, and there is no parseable output available via --status-fd X. Would it be possible to add a status message, such as [GNUPG:] WAITFORLOCK It would enable applications to help users resolve the issue. Thanks, Patrick From dkg at fifthhorseman.net Fri May 8 18:30:04 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 May 2009 12:30:04 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> Message-ID: <4A045E0C.6000304@fifthhorseman.net> On 05/07/2009 08:07 PM, David Shaw wrote: > I don't think that the SHA-1 situation is nearly that dire. What is the > attack that you're worried about here? Some attacks i'm concerned about are similar to the one demonstrated against MD5/X.509 at the end of last year: http://www.win.tue.nl/hashclash/rogue-ca/ OpenPGP is in better shape than X.509 already because there isn't a handful of central authorities that everyone chain-trusts absolutely. So there isn't room for a 'net-wide compromise of the type demonstrated by the hashclash folks. But there is still room for bogus certifications compromising pockets of the existing web of trust. > Sure, let's all switch over to > something better, but I think that the idea that we have to quickly > rebuild the web of trust or that we're somehow in a race against time > before someone starts forging signatures is more than a bit excessive. I think it *is* something of a race against time, assuming the announcement from this year's eurocrypt is legitimate. And the writing has been on the wall for SHA-1 since Wang's results in 2005, no? If we're picking arbitrary deadlines, a major user of cryptography (the US gov't) has decreed a deadline to completely abandon reliance on SHA-1 for digital signatures by the end of 2010 (19 months away). By what time do *you* think we should stop relying on SHA-1 as a community? How long do you think it will take for there to be a relatively-functional WoT if you disregard all SHA-1 certifications? How long before a practical attack along the lines of what the hashclash folks did last December against MD5 pops up, published or not? I'm not suggesting that we panic. I'm suggesting that we need to actively coordinate a retreat from the algorithm. And coordinating action on a platform as deliberately decentralized as OpenPGP is a tad more difficult than on a centralized system like X.509. Hence the politicking and prodding of the broader OpenPGP community ;) > With a new key there is no problem. If someone has a RSA or DSA2 key > already, though, and simply wants to start issuing SHA-256 signatures > instead of SHA-1, they might run into a problem. Understood. This was within my "transition to a new key" instructions, though, so i'm hoping that folks who are already ahead of the curve with greater-than-1024-bit keys (a small number, if my scan of the debian keyring is representative) will be able to sort it out for themselves. My goal was to keep those instructions relatively simple. i think they're too complicated anyway, but i did try! :( My basic goal is to ensure that this infrastructure remains robust against a determined attacker with reasonable resources. At some point (i don't know when) that's going to mean ignoring/blacklisting SHA-1 signatures. I want there to be a core of stronger signatures available *before* that happens. I welcome suggestions for other ways to do this. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri May 8 20:16:04 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 8 May 2009 14:16:04 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A045E0C.6000304@fifthhorseman.net> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> Message-ID: <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> On May 8, 2009, at 12:30 PM, Daniel Kahn Gillmor wrote: > On 05/07/2009 08:07 PM, David Shaw wrote: >> I don't think that the SHA-1 situation is nearly that dire. What >> is the >> attack that you're worried about here? > > Some attacks i'm concerned about are similar to the one demonstrated > against MD5/X.509 at the end of last year: > > http://www.win.tue.nl/hashclash/rogue-ca/ > > OpenPGP is in better shape than X.509 already because there isn't a > handful of central authorities that everyone chain-trusts absolutely. > So there isn't room for a 'net-wide compromise of the type > demonstrated > by the hashclash folks. But there is still room for bogus > certifications compromising pockets of the existing web of trust. To perform that attack requires the attacker to supply both the original key being signed as well as the new key that the attackers want the forged signature to fit. It cannot (even with MD5) be done against an arbitrary signature or key in the web of trust. Essentially it would be some attacker doing some fairly dramatic computational project to come up with two different-but-related keys. He then comes to a key signing event and gets people to sign his "A" key. Then, he moves the signatures over to his "B" key, and proceeds to wreak havoc. So two comments: 1) He can't do this to existing signatures on existing keys. He has to make a new matching A+B pair. 2) If signers use SHA-256 for new signatures, he is completely foiled. Actually, three comments: 3) *What* havoc? What does this actually enable him to do in the context of OpenPGP? For example, let's say that I have a way to perform this attack. I carefully generate my A+B key pairs, and show up to a key signing event and get lots of people to sign A. Then I move those signatures over to B. So what have I gained? In the case of rogue CA, they were able to create a certificate that turned them into a CA, but since everyone in OpenPGP is more or less a CA, that doesn't really apply here. The main thing they seem to have accomplished is to impersonate someone. So they could burn a lot of time and money in order to get some signatures on a key claiming to be someone they're not? If that's the goal, there are much easier, faster, and cheaper ways of going about it. On top of that, keep in mind that this attack is completely theoretical at this point. Nobody has ever even shown a SHA-1 collision at all, much less a collision with the kind of finesse that would be required to mount the rogue CA attack. >> Sure, let's all switch over to >> something better, but I think that the idea that we have to quickly >> rebuild the web of trust or that we're somehow in a race against time >> before someone starts forging signatures is more than a bit >> excessive. > > I think it *is* something of a race against time, assuming the > announcement from this year's eurocrypt is legitimate. And the > writing > has been on the wall for SHA-1 since Wang's results in 2005, no? No. The writing has been on the wall for *new* signatures. Compromising old signatures is a different type of failing in the hash. > If we're picking arbitrary deadlines, a major user of cryptography > (the > US gov't) has decreed a deadline to completely abandon reliance on > SHA-1 > for digital signatures by the end of 2010 (19 months away). By what > time do *you* think we should stop relying on SHA-1 as a community? I think we should stop using SHA-1 for new signatures today. It's prudent, and for all we know there will be some attack coming that nobody has conceived of yet. Stopping using SHA-1 is a good, healthy thing to do. However, there is a very substantial difference between stopping issuing new SHA-1 signatures, and proactively re-forming a new web of trust to exclude SHA-1. David From dkg at fifthhorseman.net Fri May 8 23:00:02 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 May 2009 17:00:02 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> Message-ID: <4A049D52.3000304@fifthhorseman.net> On 05/08/2009 02:16 PM, David Shaw wrote: > On May 8, 2009, at 12:30 PM, Daniel Kahn Gillmor wrote: > To perform that attack requires the attacker to supply both the original > key being signed as well as the new key that the attackers want the > forged signature to fit. It cannot (even with MD5) be done against an > arbitrary signature or key in the web of trust. Agreed. > Essentially it would be some attacker doing some fairly dramatic > computational project to come up with two different-but-related keys. > He then comes to a key signing event and gets people to sign his "A" > key. Then, he moves the signatures over to his "B" key, and proceeds to > wreak havoc. Right, this computational project is exactly what the hashclash folks did against MD5. > 1) He can't do this to existing signatures on existing keys. He has to > make a new matching A+B pair. Agreed. > 2) If signers use SHA-256 for new signatures, he is completely foiled. Right. However, if you've got a DSA-1 key, you're using SHA-1 by default, no? At best, signatures from a DSA-1 key would be made by 160-bit truncated versions of other hashes. This is good, because it's not the same algorithm that has currently been attacked. but it's also not the full-strength SHA-2 families either. > 3) *What* havoc? What does this actually enable him to do in the > context of OpenPGP? For example, let's say that I have a way to perform > this attack. I carefully generate my A+B key pairs, and show up to a > key signing event and get lots of people to sign A. Then I move those > signatures over to B. So what have I gained? In the case of rogue CA, > they were able to create a certificate that turned them into a CA, but > since everyone in OpenPGP is more or less a CA, that doesn't really > apply here. The main thing they seem to have accomplished is to > impersonate someone. So they could burn a lot of time and money in > order to get some signatures on a key claiming to be someone they're > not? If that's the goal, there are much easier, faster, and cheaper > ways of going about it. It depends on what someone has to gain from the impersonation. For example, i'm interested in seeing authentication-capable OpenPGP certificates used for ssh access (bidirectionally), and i'd like to see them useful on the web (for mutual client-server authentication). Even if you don't care about these uses, the WoT *is* a means of making impersonation more difficult online. If you don't think that strong crypto protection against impersonation is important, that's fine. But I'd like to be able to offer the people i support the ability to have their cryptosystem *not* be the weakest link in terms of identifying themselves. At the moment, there do seem to be certainly faster, easier, cheaper ways of doing it (though some organizations don't publish their results, so i can't know for certain). Anyway, I'd rather not wait until the math and CS catches up and forces our hand. > On top of that, keep in mind that this attack is completely theoretical > at this point. Nobody has ever even shown a SHA-1 collision at all, > much less a collision with the kind of finesse that would be required to > mount the rogue CA attack. Yup, i'm aware of that. I don't particularly want to see the demonstration before we switch over, though. > No. The writing has been on the wall for *new* signatures. > Compromising old signatures is a different type of failing in the hash. Sure, agreed. But i can't reliably tell a new signature from an old signature if the signature is forged ;) I also can't currently be sure that the people i communicate with aren't still issuing SHA-1 signatures in some context. Those signatures may well be made over arbitrary data supplied by a third party (have you read what passes for specs of nonsense like gpgAuth?). Those signatures are vulnerable to misuse or re-purposing. So, i have a few choices: A) decide to never trust any SHA-1 signature again as of right now, or B) continue to trust what appear to be old SHA-1 signatures, and hope that everyone has the good sense (and reliable tools) to never ever issue a signature over SHA-1 again, or C) trust SHA-1 signatures for the near term, convince everyone else to switch to something better now, and then deprecate/blacklist SHA-1 once enough people have switched, shielding myself (and other people who make the same decision) from SHA-1 problems. A an unreasonable, panicky reaction. It's also totally infeasible in today's environment. Not enough post-SHA1 signatures exist to form a reasonable WoT, none of my OpenPGP tools are even capable of deprecating SHA1 signatures, and (probably most importantly) it seems exceedingly unlikely that an attack has already been carried out. So B is unacceptable. B seems naive: i'm sure there are people who will continue making SHA-1 signatures long after the methods behind the recent exploits are widely known, perhaps because their tools are misconfigured, or their tools interpret the digest-preferences in such a way that they force the use of SHA1 for signatures or certifications in certain cases. Certifications (and other signatures) from those people/tools are now suspect, and could potentially be transplanted onto certifications which appear to be "old" (pre-attack) certs. At any rate, even if i could trust the dates on the signatures, and i could identify the users who i expect to practice good OpenPGP hygiene, i don't have any way to configure my current OpenPGP toolchain to say "Don't trust SHA-1 signatures made after $DATE" (or, more strongly, "Don't trust any SHA-1 signatures at all from $KEYID if the keyholder has made any SHA-1 signatures after $DATE" ) So C seems like a reasonable approach to me. Do you have other suggestions? > I think we should stop using SHA-1 for new signatures today. It's > prudent, and for all we know there will be some attack coming that > nobody has conceived of yet. Stopping using SHA-1 is a good, healthy > thing to do. I agree. I'd be happy if the defaults on gpg were changed to reflect this. Nonetheless, older versions of gpg will continue to exist and be used for quite a long time. > However, there is a very substantial difference between > stopping issuing new SHA-1 signatures, and proactively re-forming a new > web of trust to exclude SHA-1. yup, i agree there's a difference. But the former isn't going to happen universally, any more than MD5 was universally phased out when it became known-compromised. So since new SHA-1 signatures *will* continue to be generated, we need to consider how those of us who would prefer to not trust new signatures can move forward. One (small) piece of that transition is to make sure that a post-SHA-1 WoT exists. Currently, it's pretty weak. So i'm trying to make sure we can get that bit in place, so that the rest of the transition is possible in the future. I really appreciate the discussion on this list, by the way (not to mention the incredible infrastructure that y'all have given us in the form of gnupg). Even if we find we can't come to an agreement on the transition steps to take right now, it's certainly a respectful disagreement from my end. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From ueno at unixuser.org Sat May 9 12:02:17 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Sat, 09 May 2009 19:02:17 +0900 Subject: [PATCH] Caching symmetric encryption passphrase with gpg-agent In-Reply-To: <87ab5o7x3z.fsf@broken.deisui.org> (Daiki Ueno's message of "Fri, 08 May 2009 18:38:40 +0900") References: <87ab5o7x3z.fsf@broken.deisui.org> Message-ID: >>>>> In <87ab5o7x3z.fsf at broken.deisui.org> >>>>> Daiki Ueno wrote: > Hi, > The attached is a new patch for caching symmetric encryption passphrase > using a S2K salt as a cache key, as I proposed a couple of months ago. Sorry, the patch contains a memory leak. > --- g10/passphrase.c (revision 4996) > +++ g10/passphrase.c (working copy) > + char *cacheid = NULL; > + > + if ((mode == 3 || mode == 4) && (s2k->mode == 1 || s2k->mode == 3)) > + { > + cacheid = xmalloc (18); > + *cacheid = 'S'; > + bin2hex (s2k->salt, 8, cacheid + 1); > + } Those lines should be: char *cacheid = NULL, buf[18]; if ((mode == 3 || mode == 4) && (s2k->mode == 1 || s2k->mode == 3)) { memset (buf, 0, sizeof(buf)); *buf = 'S'; bin2hex (s2k->salt, 8, buf + 1); cacheid = buf; } Regards, -- Daiki Ueno From wk at gnupg.org Sat May 9 20:50:02 2009 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 May 2009 20:50:02 +0200 Subject: Feature Request: Parseable output if gpg waits for lock In-Reply-To: <4A04492D.40008@mozilla-enigmail.org> (Patrick Brunschwig's message of "Fri, 08 May 2009 17:01:01 +0200") References: <4A04492D.40008@mozilla-enigmail.org> Message-ID: <8763ga3ycl.fsf@wheatstone.g10code.de> On Fri, 8 May 2009 17:01, patrick at mozilla-enigmail.org said: > Would it be possible to add a status message, such as > [GNUPG:] WAITFORLOCK In theory yes, but I don't like it. gpg2 already uses a better algorithm to detected stalled processes holding a lock. For gpg1 I implemented that algorithm a few days ago. I believe that this will solve the problem. The original problem was that gpg did not remove the lock file even it the process claiming to hold the process already died - It could be mounted on NFS and thus gpg had no chance to reliable detect a stalled process. The fix implemented stores the node name in the lockfile Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From cruicky at cruicky.co.uk Sun May 10 17:11:09 2009 From: cruicky at cruicky.co.uk (J Cruickshanks) Date: Sun, 10 May 2009 16:11:09 +0100 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo Message-ID: <4A06EE8D.9030504@cruicky.co.uk> Hi there, Firstly, I should warn you this is the first set of patches I've submitted for any software ever, so please accept my apologies if something is out of order. :) With all the recent SHA-1 related news, I decided to test gpg to ensure that updated self-signatures used the algorithm specified in cert-digest-algo. I discovered that gpg takes the digest algorithm from the previous self-signature. This patch allows this behaviour to be overridden by using the digest specified by cert-digest-algo. I will be honest and say that I haven't read the full PGP specification, so this might be against it so feedback on this would be welcome. I have included 2 patches, one against 1.4.9 for people still using 1.4.9 who wish to patch, and a patch against the current SVN. Both patches have been tested to the point that they produce valid signatures using an RSA key that can be checked with --check-sigs. The patches were applied to the current source packages of gnupg and gnupg2 in Ubuntu Intrepid. I welcome your feedback on these patches. Regards J Cruickshanks P.S. Sorry to the people on the gcrypt-devel list for sending it to the wrong list first. :) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: update_keysig_packet.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: update_keysig_packet_svn.diff URL: From dshaw at jabberwocky.com Mon May 11 03:49:16 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 May 2009 21:49:16 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A049D52.3000304@fifthhorseman.net> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> Message-ID: <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> On May 8, 2009, at 5:00 PM, Daniel Kahn Gillmor wrote: >> 2) If signers use SHA-256 for new signatures, he is completely >> foiled. > > Right. However, if you've got a DSA-1 key, you're using SHA-1 by > default, no? At best, signatures from a DSA-1 key would be made by > 160-bit truncated versions of other hashes. This is good, because > it's > not the same algorithm that has currently been attacked. but it's > also > not the full-strength SHA-2 families either. Yes. I was expecting signers to use *all* of SHA-256. It would be interesting to know if the new attack works against SHA-256. Not in the sense that it could bring SHA-256 down to 2^52, but in the sense that it could bring it to something less than 2^128. > If you don't think that strong crypto protection against impersonation > is important, that's fine. But I'd like to be able to offer the > people > i support the ability to have their cryptosystem *not* be the weakest > link in terms of identifying themselves. At the moment, there do seem > to be certainly faster, easier, cheaper ways of doing it (though some > organizations don't publish their results, so i can't know for > certain). > Anyway, I'd rather not wait until the math and CS catches up and > forces > our hand. I don't mean there are faster/easier/cheaper ways of doing this mathematically. I mean boring old subterfuge like going to a keysigning party with a fake ID, claiming to be someone else. I get a bunch of signatures, and I'm done. It skips the whole difficult math problem. I'm all for strong crypto protection against impersonation, but when there is a non-crypto impersonation attack that has essentially the same end result as a crypto impersonation attack, and the non-crypto variant of the attack is vastly cheaper, faster, and easier than the crypto attack, I do start to wonder what the point is of putting a strong crypto defense against the crypto attack. > I really appreciate the discussion on this list, by the way (not to > mention the incredible infrastructure that y'all have given us in the > form of gnupg). Even if we find we can't come to an agreement on the > transition steps to take right now, it's certainly a respectful > disagreement from my end. Certainly. This is the sort of thing that reasonable people can disagree on. I don't think that your plan is wrong or evil or anything like that. I just worry it's rather eager to expunge SHA-1. The plan pushes a 3-month window to migrate to SHA-256 and revoke all earlier keys. We're not particularly close to having any collision at all, much less the finesse necessary to "weaponize" that collision generating process into an attack on OpenPGP. The plan text doesn't really say this, though, and instead puts forth a perception that is scarier than (I think) the reality is. I'm afraid that the plan document is going to result in scared people, and scared people do very dumb things. I'm already seeing various pieces of posted advice around the net to do stuff like immediately switch to 4096-bit keys or force SHA256 via 'digest-algo', or use SHA512, or other things that can actually cause more harm than good. There are a good number of ways to shoot yourself in the foot with GPG, and I've seen a good few of them in the past week or so. I suspect more are coming. People don't understand that changing their various hashes to SHA-256 pretty much puts a kink in communication between them and every version of PGP and GPG from before 2004 or so (the SHA-512 people are even worse off). But they're scared, so they do it. And there is fallout. David From rjh at sixdemonbag.org Mon May 11 04:46:15 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 10 May 2009 22:46:15 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> Message-ID: <4A079177.2020700@sixdemonbag.org> David Shaw wrote: > I'm afraid that the plan document is going to result in scared people, > and scared people do very dumb things. I'm already seeing various > pieces of posted advice around the net to do stuff like immediately > switch to 4096-bit keys or force SHA256 via 'digest-algo', or use > SHA512, or other things that can actually cause more harm than good. So here's an idea. Why not write up a recommendation, get people of repute within the community to put their names on it, then put it up somewhere that people can see it? Part of the problem we're facing is that people are scared and doing foolish things, yes -- but a major part of the problem is the lack of a coordinated message in response. There has been a lot of good advice coming from people, but it's scattershot, and drowns out in a sea of bad advice. It would be helpful to have a single, central recommendation. If there's interest, I'll take a stab at a rough draft of it. From dkg at fifthhorseman.net Mon May 11 07:21:04 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 May 2009 01:21:04 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A079177.2020700@sixdemonbag.org> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <4A079177.2020700@sixdemonbag.org> Message-ID: <4A07B5C0.9040107@fifthhorseman.net> On 05/10/2009 10:46 PM, Robert J. Hansen wrote: > So here's an idea. Why not write up a recommendation, get people of > repute within the community to put their names on it, then put it up > somewhere that people can see it? Part of the problem we're facing is > that people are scared and doing foolish things, yes -- but a major part > of the problem is the lack of a coordinated message in response. > > There has been a lot of good advice coming from people, but it's > scattershot, and drowns out in a sea of bad advice. It would be helpful > to have a single, central recommendation. I basically wrote that blog entry because i didn't see any concrete recommendations coming out, felt that something was needed, and i took my best shot at it. I would really welcome clear recommendations (and descriptions of forseen problems) from experienced people. > If there's interest, I'll take a stab at a rough draft of it. I'd be very interested to read a draft, thanks for offering. If you're willing to publish it, i'd certainly link to such a statement from my blog post (which appears to have caused a stir within debian), whether it ends in general agreement or in sharp criticism. Thanks for the discussion, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon May 11 07:26:30 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 May 2009 01:26:30 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> Message-ID: <4A07B706.1010400@fifthhorseman.net> On 05/10/2009 09:49 PM, David Shaw wrote: > On May 8, 2009, at 5:00 PM, Daniel Kahn Gillmor wrote: > It would be interesting to know if the new attack works against > SHA-256. Not in the sense that it could bring SHA-256 down to 2^52, but > in the sense that it could bring it to something less than 2^128. Indeed. I wish i understood the math behind all this more clearly :( > I don't mean there are faster/easier/cheaper ways of doing this > mathematically. I mean boring old subterfuge like going to a keysigning > party with a fake ID, claiming to be someone else. I get a bunch of > signatures, and I'm done. It skips the whole difficult math problem. Yeah, i understood what you were driving at. I agree that the social protocols are far easier to crack than the crypto right now. And i'd like to see that stay the same, actually, since the crypto is actually easier to get right (in the tool chain) than user education (which has to happen with each individual, fallible human). I just want to be sure that people who *do* think about the security implications of their decisions and actions will have a toolchain that is comparably secure, even in the face of a mathematically- and computationally-sophisticated adversary. > Certainly. This is the sort of thing that reasonable people can > disagree on. I don't think that your plan is wrong or evil or anything > like that. I just worry it's rather eager to expunge SHA-1. The plan > pushes a 3-month window to migrate to SHA-256 and revoke all earlier > keys. We're not particularly close to having any collision at all, much > less the finesse necessary to "weaponize" that collision generating > process into an attack on OpenPGP. The plan text doesn't really say > this, though, and instead puts forth a perception that is scarier than > (I think) the reality is. Yeah, this is a tradeoff i had difficulty making, and it looks like i drew the line differently than you would have. I was balancing between making a non-panicked, concise post with concrete, relatively simple recommendations, and a more lengthy, nuanced, non-panicked discussion about the various factors in play along with a concrete list of next-step actions. I opted for the shorter version in the hopes that people would actually read the post and take the actions described :/ > I'm afraid that the plan document is going to result in scared people, > and scared people do very dumb things. I'm already seeing various > pieces of posted advice around the net to do stuff like immediately > switch to 4096-bit keys or force SHA256 via 'digest-algo', or use > SHA512, or other things that can actually cause more harm than good. For the record, i've been using 4096-bit OpenPGP keys for about 20 months now (without incident), and have just started using signatures over SHA-512, mainly because i'm interested in seeing what actually does break. I plan on publicizing such breakage as soon as it happens so other folks can know about it. Basically, i'm willing to be a guinea pig. I grant that most of my cryptographic communications (authenticated and/or private) tend to be in the free software world, though, so i might not be the best judge of interoperability with non-free tools. It would be great if someone who does have those interoperability concerns wanted to write up specific harms that can arise from these choices. I'm going to point to the archive of this discussion from my blog post so that these perspectives get some exposure. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From patrick at mozilla-enigmail.org Mon May 11 10:23:40 2009 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon, 11 May 2009 10:23:40 +0200 Subject: Feature Request: Parseable output if gpg waits for lock In-Reply-To: <8763ga3ycl.fsf@wheatstone.g10code.de> References: <4A04492D.40008@mozilla-enigmail.org> <8763ga3ycl.fsf@wheatstone.g10code.de> Message-ID: <4A07E08C.6020508@mozilla-enigmail.org> Werner Koch wrote: > On Fri, 8 May 2009 17:01, patrick at mozilla-enigmail.org said: > >> Would it be possible to add a status message, such as >> [GNUPG:] WAITFORLOCK > > In theory yes, but I don't like it. > > gpg2 already uses a better algorithm to detected stalled processes > holding a lock. For gpg1 I implemented that algorithm a few days ago. > > I believe that this will solve the problem. > > The original problem was that gpg did not remove the lock file even it > the process claiming to hold the process already died - It could be > mounted on NFS and thus gpg had no chance to reliable detect a stalled > process. The fix implemented stores the node name in the lockfile Even better, then I won't need to worry anymore :-) -Patrick From wk at gnupg.org Mon May 11 18:48:13 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 May 2009 18:48:13 +0200 Subject: Default encryption key algo Message-ID: <87eiuvr3g2.fsf@wheatstone.g10code.de> Hi, from all responses we gathered regarding the change of the default algorithm for new keys (on several lists) it should be pretty clear that RSA is a good choice. The next question is whether to use Elgamal or RSA as the standard encryption subkey for a new key. Currently it is Elgamal. They are both okay: Elgamal needs to be supported anyway becuase it is a MUST algorithm in OpenPGP and RSA can be used because the primary key will be RSA and an implementation without RSA support won't be able to use an Elgamal subkey either. I have a slight preference towards RSA because that allows to transfer the key to a smartcard. Given that subkeys are easily changeable it is not a real advantage, though. Any opinions? What is PGP's default? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon May 11 19:16:43 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 May 2009 13:16:43 -0400 Subject: Default encryption key algo In-Reply-To: <87eiuvr3g2.fsf@wheatstone.g10code.de> References: <87eiuvr3g2.fsf@wheatstone.g10code.de> Message-ID: On May 11, 2009, at 12:48 PM, Werner Koch wrote: > Hi, > > from all responses we gathered regarding the change of the default > algorithm for new keys (on several lists) it should be pretty clear > that > RSA is a good choice. > > The next question is whether to use Elgamal or RSA as the standard > encryption subkey for a new key. Currently it is Elgamal. They are > both okay: Elgamal needs to be supported anyway becuase it is a MUST > algorithm in OpenPGP and RSA can be used because the primary key > will be > RSA and an implementation without RSA support won't be able to use an > Elgamal subkey either. > > I have a slight preference towards RSA because that allows to transfer > the key to a smartcard. Given that subkeys are easily changeable it > is > not a real advantage, though. > > Any opinions? What is PGP's default? PGP's default is RSA. They don't really mix key types very much in the UI. They either do DSA/Elgamal or RSA/RSA. The smartcard is a good reason to choose RSA, I'd say. (Speaking of which, do you know when the new cards will be available?) David From dkg at fifthhorseman.net Mon May 11 19:29:16 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 May 2009 13:29:16 -0400 Subject: Default encryption key algo In-Reply-To: References: <87eiuvr3g2.fsf@wheatstone.g10code.de> Message-ID: <4A08606C.2020908@fifthhorseman.net> On 05/11/2009 01:16 PM, David Shaw wrote: > PGP's default is RSA. They don't really mix key types very much in the > UI. They either do DSA/Elgamal or RSA/RSA. > > The smartcard is a good reason to choose RSA, I'd say. (Speaking of > which, do you know when the new cards will be available?) RSA seems reasonable to me also, for whatever that's worth. I've been using RSA encryption-capable subkeys for nearly 2 years with no negative incidents. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 11 19:17:23 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 May 2009 19:17:23 +0200 Subject: Default encryption key algo In-Reply-To: (David Shaw's message of "Mon, 11 May 2009 13:16:43 -0400") References: <87eiuvr3g2.fsf@wheatstone.g10code.de> Message-ID: <87ab5j1rvg.fsf@wheatstone.g10code.de> On Mon, 11 May 2009 19:16, dshaw at jabberwocky.com said: > The smartcard is a good reason to choose RSA, I'd say. (Speaking of > which, do you know when the new cards will be available?) I have two test cards already. I guess we can ship cards this summer. However the distributor has to decide and thus it may be helpful if you don't stop buying the old cards right now. There are about 300 produced cards left over. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon May 11 19:38:34 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 May 2009 19:38:34 +0200 Subject: Omnikey readers and 2048 bit keys Message-ID: <871vqv1qw5.fsf@wheatstone.g10code.de> Hi! While testing the new 2048 bit smartcards I figured that all Omnikey based readers (e.g. CardMan, Cherry keyboards) won't work. SCM readers work just fine. See http://pcsclite.alioth.debian.org/ccid_extended_apdu.html for details. The interesting thing is that they seem to work on Windows (at least Cardman 3121 and 5121): This seems to be due to tricks in the Windows driver. I guess they are switching the reader to TPDU mode or some raw mode. Simply trying to use extended length APDU exchange does not work. I started to do a protocol analysis of the CCID data send over USB but due to problems with Windows XP's resource manager when running under KVM, I have postponed it for now. If you want to work on it, there is a little tool in GnuPG's SVN: tools/ccidmon.c to prins the CCID protocol data in an easy readable format. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rjh at sixdemonbag.org Mon May 11 19:58:23 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 May 2009 13:58:23 -0400 Subject: Default encryption key algo In-Reply-To: <87eiuvr3g2.fsf@wheatstone.g10code.de> References: <87eiuvr3g2.fsf@wheatstone.g10code.de> Message-ID: <4A08673F.2090106@sixdemonbag.org> Werner Koch wrote: > I have a slight preference towards RSA because that allows to transfer > the key to a smartcard. Given that subkeys are easily changeable it is > not a real advantage, though. I vote for RSA because I'm getting pretty tired of the fixed-size hashes associated with the various DSAs. This seems to be the cause of a remarkable number of requests for help on various mailing lists. RSA makes it easier for end users to switch their hash algorithms, and that's plenty good enough reason for me. From jmoore3rd at bellsouth.net Mon May 11 23:55:18 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 11 May 2009 17:55:18 -0400 Subject: Default encryption key algo In-Reply-To: <87eiuvr3g2.fsf@wheatstone.g10code.de> References: <87eiuvr3g2.fsf@wheatstone.g10code.de> Message-ID: <4A089EC6.3090004@bellsouth.net> Werner Koch wrote: > The next question is whether to use Elgamal or RSA as the standard > encryption subkey for a new key. Currently it is Elgamal. They are > both okay: Elgamal needs to be supported anyway becuase it is a MUST > algorithm in OpenPGP and RSA can be used because the primary key will be > RSA and an implementation without RSA support won't be able to use an > Elgamal subkey either. > > I have a slight preference towards RSA because that allows to transfer > the key to a smartcard. Given that subkeys are easily changeable it is > not a real advantage, though. > > Any opinions? What is PGP's default? Having no clue as to PGP's current 'default' I can only express My Personal Opinion. That is that I feel that Elgamal, bit for bit, is 'stronger' but I cannot expressly defend that at present. :-\ JOHN 8-) Timestamp: Monday 11 May 2009, 17:54 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue May 12 09:47:08 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 May 2009 09:47:08 +0200 Subject: Default encryption key algo In-Reply-To: <4A08673F.2090106@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 11 May 2009 13:58:23 -0400") References: <87eiuvr3g2.fsf@wheatstone.g10code.de> <4A08673F.2090106@sixdemonbag.org> Message-ID: <87skjazrsz.fsf@wheatstone.g10code.de> On Mon, 11 May 2009 19:58, rjh at sixdemonbag.org said: > I vote for RSA because I'm getting pretty tired of the fixed-size hashes > associated with the various DSAs. This seems to be the cause of a Well, in this case it doesn't matter becuase the default subkey is for encryption only. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Tue May 12 15:42:28 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 May 2009 09:42:28 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4A06EE8D.9030504@cruicky.co.uk> References: <4A06EE8D.9030504@cruicky.co.uk> Message-ID: On May 10, 2009, at 11:11 AM, J Cruickshanks wrote: > Hi there, > > Firstly, I should warn you this is the first set of patches I've > submitted for any software ever, so please accept my apologies if > something is out of order. :) > > With all the recent SHA-1 related news, I decided to test gpg to > ensure > that updated self-signatures used the algorithm specified in > cert-digest-algo. I discovered that gpg takes the digest algorithm > from > the previous self-signature. This patch allows this behaviour to be > overridden by using the digest specified by cert-digest-algo. I will > be > honest and say that I haven't read the full PGP specification, so this > might be against it so feedback on this would be welcome. I don't think it's against the standard, and I do think the patch does what you set out to do, but I have a concern whether this is something we want to do in the code. update_keysig_packet is called for expiration changes, backsig additions, setting the primary uid, updating preferences and the preferred keyserver, and adding notations. All of these items involve manipulating an existing, and presumably working, signature (i.e. the update cases, hence the function name). This patch would mean that when updating these signatures, the signature hash may also be changed, as a secondary item. So if the user changes the primary UID flag, they'll get a new cert hash at the same time. This is fine if someone intended to do that, but less fine if it happens as an unexpected side-effect of doing something as simple as setting the primary UID flag. We still live in a world where a good percentage of the installed code base cannot understand things like SHA256 (and fewer can understand SHA512 or 384), so I think this violates the principle of least surprise - people should not be able to easily render their keys unusable by some percentage of the population without doing that on purpose. (It's actually a bit more complex than this if people are using the keyserver net to distribute their keys, but the basic point is the same). So all that said, if the goal is a new self sig, just sign your own UID like you'd sign any other UID. GPG will recognize that it needs to make a self-signature, and will properly add the various self-sig things like preferences and such. gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey delsig (the old sig) sign (make the new sig) save David From dkg at fifthhorseman.net Tue May 12 17:13:48 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 May 2009 11:13:48 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: References: <4A06EE8D.9030504@cruicky.co.uk> Message-ID: <4A09922C.9050100@fifthhorseman.net> On 05/12/2009 09:42 AM, David Shaw wrote: > This patch would mean that when updating these signatures, the signature > hash may also be changed, as a secondary item. So if the user changes > the primary UID flag, they'll get a new cert hash at the same time. > This is fine if someone intended to do that, but less fine if it happens > as an unexpected side-effect of doing something as simple as setting the > primary UID flag. So what if the update process produced a warning prompt to query if the user really wants the digest algorithm to change? If people don't like the idea of adding an additional warning in some cases, (e.g. it might interrupt automated workflow for some users), why not instead at least warn that --cert-digest-algo is not being honored? > We still live in a world where a good percentage of the installed code > base cannot understand things like SHA256 (and fewer can understand > SHA512 or 384), so I think this violates the principle of least surprise I understand what you're saying. However, i also think it violates the principle of least-surprise to do something that you *know* updates your self-sig (e.g. setpref) and see gpg not honor the explicitly-specified --cert-digest-algo). > So all that said, if the goal is a new self sig, just sign your own UID > like you'd sign any other UID. GPG will recognize that it needs to make > a self-signature, and will properly add the various self-sig things like > preferences and such. > > gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey > delsig (the old sig) > sign (make the new sig) > save For users with several UIDs where each UID has dozens of signatures, the delsig step at least is a serious pain in the neck. Why should the user need to go through such a rigamarole just to be able to publish a stronger self-sig for those clients capable of consuming it? Here's an idea that might answer both concerns: Making a self-signature when cert-digest-algo is set to something other than SHA1 could generate *two* self-signatures per UID: * an SHA-1-based self-sig (timestamped X) for consumption by clients who cannot handle other digests, and * a self-sig using cert-digest-algo (timestamped X+1) for consumption by clients who *can* handle the newer digests (and who may wish at some point to deprecate SHA-1 sigs). Both self-sigs would contain identical subpackets other than the digest algo and the timestamp. The result of this would be that all compliant OpenPGP clients would get the same information, and clients who prefer stronger digests can get the additional assurance provided by the --cert-digest-algo. Since self-sigs are made over data entirely under the control of the keyholder, there is no risk that the act of making a self-signature over SHA-1 could be abused by someone exploiting the digest's weakened collision resistance. Thoughts? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From cruicky at cruicky.co.uk Tue May 12 17:23:01 2009 From: cruicky at cruicky.co.uk (J Cruickshanks) Date: Tue, 12 May 2009 16:23:01 +0100 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: References: <4A06EE8D.9030504@cruicky.co.uk> Message-ID: <4A099455.3080104@cruicky.co.uk> David Shaw wrote: > This patch would mean that when updating these signatures, the signature > hash may also be changed, as a secondary item. So if the user changes > the primary UID flag, they'll get a new cert hash at the same time. > This is fine if someone intended to do that, but less fine if it happens > as an unexpected side-effect of doing something as simple as setting the > primary UID flag. > > We still live in a world where a good percentage of the installed code > base cannot understand things like SHA256 (and fewer can understand > SHA512 or 384), so I think this violates the principle of least surprise > - people should not be able to easily render their keys unusable by some > percentage of the population without doing that on purpose. (It's > actually a bit more complex than this if people are using the keyserver > net to distribute their keys, but the basic point is the same). > > So all that said, if the goal is a new self sig, just sign your own UID > like you'd sign any other UID. GPG will recognize that it needs to make > a self-signature, and will properly add the various self-sig things like > preferences and such. > > gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey > delsig (the old sig) > sign (make the new sig) > save The method you have described appears to work successfully. It does however have the side effect of wiping away any preferences you already have set, therefore they need to be set again. I would also assume that expiry dates and primary UIDs would also have to be set again. I agree that the user must be fully aware of what they are doing when making a change like this as it is pretty aggressive. Perhaps an alternative to the above method could be the addition of a new option called something along the lines of '--force-cert-digest-algo'. This would be used in addition to '--cert-digest-algo' for updating self signatures when changing preferences, expiry dates, etc. along with changing the digest algorithm for the first time the user wishes to use a new digest algorithm. We can then be reasonably sure the user intended for the digest function to be changed. This option would then of course be accompanied by a warning much like for the '--cert-digest-algo' option in the man page. As I mentioned above, this option would probably only be used once or twice depending on the future of cryptography, so we could stick with the method you have provided for updating the digest. The only worry I have with that approach is the potential for the user to forget to reapply their preferences, expiry dates, etc. or getting caught out by other side effects that I didn't witness in my quick test. I guess it depends on how much usage this option will get as to whether to warrant its inclusion, but it would make the process much easier for users who do wish to change digest algorithms. If you believe that this approach would be better, I will be quite willing to write a patch for the option. Regards J Cruickshanks From dshaw at jabberwocky.com Tue May 12 17:45:23 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 May 2009 11:45:23 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4A09922C.9050100@fifthhorseman.net> References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> Message-ID: <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> On May 12, 2009, at 11:13 AM, Daniel Kahn Gillmor wrote: > On 05/12/2009 09:42 AM, David Shaw wrote: >> This patch would mean that when updating these signatures, the >> signature >> hash may also be changed, as a secondary item. So if the user >> changes >> the primary UID flag, they'll get a new cert hash at the same time. >> This is fine if someone intended to do that, but less fine if it >> happens >> as an unexpected side-effect of doing something as simple as >> setting the >> primary UID flag. > > So what if the update process produced a warning prompt to query if > the > user really wants the digest algorithm to change? > > If people don't like the idea of adding an additional warning in some > cases, (e.g. it might interrupt automated workflow for some users), > why > not instead at least warn that --cert-digest-algo is not being > honored? > >> We still live in a world where a good percentage of the installed >> code >> base cannot understand things like SHA256 (and fewer can understand >> SHA512 or 384), so I think this violates the principle of least >> surprise > > I understand what you're saying. However, i also think it violates > the > principle of least-surprise to do something that you *know* updates > your > self-sig (e.g. setpref) and see gpg not honor the explicitly-specified > --cert-digest-algo). You know that. I'd be shocked to my core to find out that more than 5-10% of randomly chosen OpenPGP users have any understanding at all that preferences are stored on the self-sig, that a valid self-sig is required to have a usable key, and that remaking the self-sig using a hash that doesn't exist on the recipient side will cause that recipient to not be able to use the key at all. >> So all that said, if the goal is a new self sig, just sign your own >> UID >> like you'd sign any other UID. GPG will recognize that it needs to >> make >> a self-signature, and will properly add the various self-sig things >> like >> preferences and such. >> >> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey >> delsig (the old sig) >> sign (make the new sig) >> save > > For users with several UIDs where each UID has dozens of signatures, > the > delsig step at least is a serious pain in the neck. Why should the > user > need to go through such a rigamarole just to be able to publish a > stronger self-sig for those clients capable of consuming it? Because there are vastly more users who don't want to do this. > Here's an idea that might answer both concerns: > > Making a self-signature when cert-digest-algo is set to something > other > than SHA1 could generate *two* self-signatures per UID: > > * an SHA-1-based self-sig (timestamped X) for consumption by clients > who cannot handle other digests, and > > * a self-sig using cert-digest-algo (timestamped X+1) for consumption > by clients who *can* handle the newer digests (and who may wish at > some > point to deprecate SHA-1 sigs). > > Both self-sigs would contain identical subpackets other than the > digest > algo and the timestamp. It's always possible to come up with a complex solution, but then that complexity may have other side effects down the road, and will also have to be maintained as a feature in GPG for the indefinite future. > Since > self-sigs are made over data entirely under the control of the > keyholder, there is no risk that the act of making a self-signature > over > SHA-1 could be abused by someone exploiting the digest's weakened > collision resistance. So then why is any of this necessary? David From dshaw at jabberwocky.com Tue May 12 17:52:56 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 May 2009 11:52:56 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4A099455.3080104@cruicky.co.uk> References: <4A06EE8D.9030504@cruicky.co.uk> <4A099455.3080104@cruicky.co.uk> Message-ID: On May 12, 2009, at 11:23 AM, J Cruickshanks wrote: >> gpg --cert-digest-algo the-new-algo -u mykey --edit-key mykey >> delsig (the old sig) >> sign (make the new sig) >> save > > The method you have described appears to work successfully. It does > however have the side effect of wiping away any preferences you > already > have set, therefore they need to be set again. I would also assume > that > expiry dates and primary UIDs would also have to be set again. That is correct, yes. > As I mentioned above, this option would probably only be used once or > twice depending on the future of cryptography, so we could stick with > the method you have provided for updating the digest. The only worry I > have with that approach is the potential for the user to forget to > reapply their preferences, expiry dates, etc. or getting caught out by > other side effects that I didn't witness in my quick test. I guess it > depends on how much usage this option will get as to whether to > warrant > its inclusion, but it would make the process much easier for users who > do wish to change digest algorithms. This is exactly my concern - we can put in all sorts of options, but every option costs something to maintain it over the life of the code, and costs something to document, and costs something to explain it to people, and increases the complexity of the system. If hashes were falling like flies and people were having to update their keys frequently, I'd probably feel differently about this, but the SHA-1 problem (which I must mention still hasn't even happened) is the very first time this situation has come up in OpenPGP. (MD5 was already deprecated by the time it was broken, and was never the default signing hash in any OpenPGP application). David From dkg at fifthhorseman.net Tue May 12 18:51:17 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 May 2009 12:51:17 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> Message-ID: <4A09A905.4040205@fifthhorseman.net> On 05/12/2009 11:45 AM, David Shaw wrote: > On May 12, 2009, at 11:13 AM, Daniel Kahn Gillmor wrote: >> Since >> self-sigs are made over data entirely under the control of the >> keyholder, there is no risk that the act of making a self-signature over >> SHA-1 could be abused by someone exploiting the digest's weakened >> collision resistance. > > So then why is any of this necessary? Because while *making* self-sigs doesn't make the keyholder more vulnerable to a digest compromise, *trusting* self-sigs leaves the interpreter vulnerable to a digest compromise. See my followup yesterday on ietf-openpgp: http://www.imc.org/ietf-openpgp/mail-archive/msg33452.html So anyone checking signatures for validity has a good reason to ignore signatures (self-sigs or otherwise) made over untrustworthy digests. Since this is the case, people who want their certifications to be deemed valid by everyone have an incentive to make those certifications over digests that are not known to be compromised. At the moment, you're saying there is a non-zero installed base of clients that do not support signatures made over SHA-256. In the future, there may be a non-zero base of clients who prefer to disbelieve (blacklist) signatures made over SHA-1. If gpg wants its generated self-signatures to be acceptable to members of both of these sets, it must issue two signatures (one over each digest). You cannot issue two self-sigs like this in gpg right now without the --expert option, which indicates that it's probably the wrong way to do things. If a gpg user wants to ignore either set of clients, the obvious way to do that is by setting cert-digest-algo. But that doesn't currently behave as expected, as J Cruickshanks pointed out. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue May 12 19:27:15 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 May 2009 13:27:15 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4A09A905.4040205@fifthhorseman.net> References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> <4A09A905.4040205@fifthhorseman.net> Message-ID: <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> On May 12, 2009, at 12:51 PM, Daniel Kahn Gillmor wrote: > If gpg wants its generated self-signatures to be acceptable to members > of both of these sets, it must issue two signatures (one over each > digest). You cannot issue two self-sigs like this in gpg right now > without the --expert option, which indicates that it's probably the > wrong way to do things. I do understand what you are asking for. I just disagree that it is warranted for SHA-1 at this time. This is not a perfect world where as soon as there was a question even asked about an algorithm, we could just shove it aside and use something else. This is a very messy world where the vast majority of users don't upgrade, don't use the latest algorithms, and don't even understand the problem. There are tools within GPG to accomplish what you want to do today. It may not be as neat as a new feature, but you, nor anyone else who feels the need to do this, are not being blocked for lack of this feature. Again, if we were in the position of changing digest hashes more often than once a decade, I might feel differently about some spiffy new feature to automate it, but this is the first time it's been necessary since 1997. David From dkg at fifthhorseman.net Tue May 12 22:05:10 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 May 2009 16:05:10 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> <4A09A905.4040205@fifthhorseman.net> <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> Message-ID: <4A09D676.8030307@fifthhorseman.net> On 05/12/2009 01:27 PM, David Shaw wrote: > This is not a perfect world where as > soon as there was a question even asked about an algorithm, we could > just shove it aside and use something else. This is a very messy world > where the vast majority of users don't upgrade, don't use the latest > algorithms, and don't even understand the problem. Agreed, and i'm *not* suggesting that we should cast SHA-1 aside right now. The fact that the majority of users don't understand the problem and take a long time to upgrade is an indication that we need tools to do the Right Thing proactively, well before the "weaponized" attacks are created. The tools we release this year will likely still be in use 5 years from now, in a different cryptographic landscape, on behalf of those same users who don't understand the issues. I can think of two situations where the set of users who decline to rely on SHA-1-based signatures will be a significantly larger than the empty set: * When an "weaponized" attack against SHA-1's collision-resistance does come out, or * When a large organization decides that SHA-1 is no longer trustworthy, and mandates that signatures based on it be disregarded (for example, the US Federal Gov't will do this at the end of 2010). When either event happens, the current WoT will suffer. For example, all the published sigs (self-sigs and those made by others) on 0x99242560 are made with either MD5 or SHA1. Even if all of your correspondents were to re-issue their certifications over stronger digests, your key would not be considered valid by someone choosing to deprecate SHA-1 because your self-sigs are made over the compromised algorithm. So, before either of these two events happen, we need a couple things to already be comfortably in place: A) we'll need tools that are capable of simply deprecating signatures made over SHA-1 (see the earlier discussion about blacklist-digest-algo) B) we'll need a WoT with sufficient post-SHA1 certifications to provide useful connectivity. As the widest-used free implementation of OpenPGP, gnupg is in a unique position to make sure that both of these things happen. My proposal adds no new UI features to gpg, and is a simple rule: * if cert-digest-algo is not SHA-1, gnupg generates all self-signatures twice, over SHA-1 and cert-digest-algo If blacklist-digest-algo was currently implemented, we could consider expanding this rule to: * if cert-digest-algo is not SHA-1, and SHA-1 is not blacklisted, gnupg generates all certifications (self-sigs and otherwise) twice, over SHA-1 and cert-digest-algo. If we make this change now, then users stuck on, say, debian oldstable 3 years from now (about the time SHA-3 will be finalized, if i'm reading the timetable correctly, and well after the US Gov't has started ignoring SHA-1 signatures) have a chance at being able to interact with the OpenPGP WoT where a significant set of their correspondents have deprecated SHA-1-based signatures. Since gpg would make SHA-1 self-sigs as well under this scenario, it would not cause users today to cut themselves off from current populations of users with minimal implementations which can only handle SHA-1. > There are tools within GPG to accomplish what you want to do today. It > may not be as neat as a new feature, but you, nor anyone else who feels > the need to do this, are not being blocked for lack of this feature. I've already done it, but it was confusing and more complicated than it needed to be, even for someone who is heavily invested in understanding the detailed issues here. I'm concerned about the majority of users who, as you say, don't even understand the problem. gnupg can make things work securely for them, and help to maintain the global WoT without requiring each user to jump through the same hoops i did. > Again, if we were in the position of changing digest hashes more often > than once a decade, I might feel differently about some spiffy new > feature to automate it, but this is the first time it's been necessary > since 1997. So how do you suggest we prepare for this transition? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed May 13 05:04:56 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 May 2009 23:04:56 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4A09D676.8030307@fifthhorseman.net> References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> <4A09A905.4040205@fifthhorseman.net> <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> <4A09D676.8030307@fifthhorseman.net> Message-ID: <770ED08D-078D-4A39-BC67-1BA556A2B00A@jabberwocky.com> On May 12, 2009, at 4:05 PM, Daniel Kahn Gillmor wrote: > So how do you suggest we prepare for this transition? By not assuming things. We don't know the details. What we don't know is much greater than what we do know. Do you know what doubling signatures with do for the various currently deployed OpenPGP clients out there? Will they all do the right thing? How many will break? It's not enough to test against yourself here - from your blog posting, I understand you are communicating mainly with Debian developers, virtually all of which are running a somewhat recent version of GPG. And all this before the paper describing the attack is even published! Do we know the details of the attack? No. Do we know if the attack works against SHA-2? It might - both SHA-1 and the SHA-2 family share the same basic construction. Does the extra size of SHA-2 give enough buffer to avoid the attack? Probably, but we don't know yet. Are we safe until SHA-3 is ready? Maybe, maybe not. We've only seen a few powerpoint slides. Have you ever heard the old trope "Something must be done. This is something. Therefore, this must be done" ? This is a bit like that. Coming up with a defense against what we *think* the attack is is a dicey business, especially when we can wait just a little while for the paper to be published and then we can come up with a defense against what we *know* the attack is. No matter what the attack turns out to be, I feel confident in saying that we are at least safe until the paper appears. David From wk at gnupg.org Wed May 13 14:53:40 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 May 2009 14:53:40 +0200 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <4A09D676.8030307@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 12 May 2009 16:05:10 -0400") References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> <4A09A905.4040205@fifthhorseman.net> <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> <4A09D676.8030307@fifthhorseman.net> Message-ID: <87ljp1xiy3.fsf@wheatstone.g10code.de> On Tue, 12 May 2009 22:05, dkg at fifthhorseman.net said: > do the Right Thing proactively, well before the "weaponized" attacks are > created. The tools we release this year will likely still be in use 5 > years from now, in a different cryptographic landscape, on behalf of > those same users who don't understand the issues. We should get things back to reality. First of all there is no attack on SHA-1. Maybe it will be possible to mount a collision attack in a couple of years. Maybe it will then be possible to attack the web of trust or do any other collision based evil. These are and will be targeted attacks on certain infrastructures. Folks responsible for these infrastructures need to care about it and put possible collision attacks on their list of attack scenarios. This is nothing the average user needs to care about. We don't need to prioritize pro-active changes of active keys either. If real harm will be possible everyone who cares about security just creates a vanilla new key and is done. A key replacement strategy needs to be in place anyway. Those who don't like that should have the knowledge how to modify their own keys. Things to keep in mind: - The web-of-trust is an ad-doc structure and its security margin is for sure far far less then 2^52. Attacking the WoT is far easier than mounting an collision attack on SHA-1. Even without doing rubber hose cryptanalysis. - There are tools implementing the security (e.g. gpg). Assuming that these tools are bug free or at least that these bugs are harder to find and exploit than to mount a real world SHA-1 collision attack, is plainly wrong. Those who believe that should do a reality check. - There are other application on the box running the tools: Are they secure enough? I doubt that. - There is an operating system involved. Is it really secure enough? I doubt that too. - I guess that at least 99 percent of all users are not able to keep their environment hardened against simple attacks. Why should we then harden the existing keys automagically and risking interoperability problems which will in turn lead to decreased security. Again: Those who rely on nearly perfect security know about the problems and can develop ways to mitigate that. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From micah at riseup.net Thu May 14 16:35:01 2009 From: micah at riseup.net (Micah Anderson) Date: Thu, 14 May 2009 10:35:01 -0400 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> <4A09A905.4040205@fifthhorseman.net> <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> <4A09D676.8030307@fifthhorseman.net> <87ljp1xiy3.fsf@wheatstone.g10code.de> Message-ID: <871vqr4usq.fsf@pond.riseup.net> Werner Koch writes: > On Tue, 12 May 2009 22:05, dkg at fifthhorseman.net said: > >> do the Right Thing proactively, well before the "weaponized" attacks are >> created. The tools we release this year will likely still be in use 5 >> years from now, in a different cryptographic landscape, on behalf of >> those same users who don't understand the issues. > > We should get things back to reality. > > First of all there is no attack on SHA-1. Maybe it will be possible to > mount a collision attack in a couple of years. Maybe it will then be > possible to attack the web of trust or do any other collision based > evil. I appreciate you bringing us back to reality(tm), grounding this discussion is helpful. However, the first sentence of what you said was grounded in reality, but then you immediately stepped into speculation. You are right that 'maybe it will be possible to mount a collision attack in a couple of years', but I would be just as right to say that 'maybe it will be possible to mount a collision attack in a couple of weeks'.... we do not really know where this will fall. I think the 'reality' is that we can all agree that a collision attack on SHA-1 will come, *at some point*. It might be in 4 years, or it might be in 2, or someone might be working on polishing their powerpoint slides right now. The reality here is the following: the reduction in keyspace travel could point to a trend similar to what happened with MD-5 (ie. further reductions are to be expected). Based on this, we can expect that some point SHA-1 will have a collision attack that is relatively trivial. At the moment, we have a strong indication that collisions with SHA-1 are within the reach of Well Funded Organizations, but we do not have the actual published paper yet. > This is nothing the average user needs to care about. We don't need > to prioritize pro-active changes of active keys either. Ok, if this is nothing that the average user needs to care about, then what does the gnupg development need to think about? I don't want to claim that interoperability is not important, but I do think that gnupg, as the flagship free OpenPGP implementation, should take the responsible lead and push the Web of Trust to do the right thing. GnuPG already drives the WOT, and has the ability to nudge it in positive and coherent directions, or not. We all recognize the reality that key transitions take a long time, a really long time. Anyone who has done it understands this very well. We know, without any conjecture, that there is no demonstrated problem right now (if you ignore the fact that collisions in the key space are now within the reach of Well Funded Organizations, which I personally do not think is something that should be ignored in a cavalier manner). Because there is no problem right now, we have the space to work on this problem, without a hasty rush that could lead to problems. Lets think a couple of steps ahead, be slightly cautious, and come out the other end as having the foresight to deal with this problem gracefully before it hit us. Lets actually plan for the future, instead of deferring that planning. > - The web-of-trust is an ad-doc structure and its security margin is > for sure far far less then 2^52. Attacking the WoT is far easier > than mounting an collision attack on SHA-1. Even without doing > rubber hose cryptanalysis. > > - There are tools implementing the security (e.g. gpg). Assuming that > these tools are bug free or at least that these bugs are harder to > find and exploit than to mount a real world SHA-1 collision attack, > is plainly wrong. Those who believe that should do a reality check. > > - There are other application on the box running the tools: Are they > secure enough? I doubt that. > > - There is an operating system involved. Is it really secure enough? > I doubt that too. > > - I guess that at least 99 percent of all users are not able to keep > their environment hardened against simple attacks. There are always going to be other weaknesses, but thats not an excuse for gnupg to not try to be better. All of these things need to be improved, but doing so is not the role of gnupg. This list is for gnupg development, not a list about Windows security, or whatever. Each one of these pieces does need work, I'm not going to dispute that, but that work should not lull gnupg into inaction. Gnupg has its role to play and it should take that role and run with it, blazing the crypto trail. > Why should we then harden the existing keys automagically and risking > interoperability problems which will in turn lead to decreased security. I may be an outlier here, but those 5-year old programs that will have interoperability problems are going to have other issues that significantly reduce their security. We should not let old software that has *worse* security holes hold us back. We *can* lead and people *will* upgrade. At some point Firefox was also faced with this decision: should they push for a better web, knowing that they will cause the older browsers to have interoperability problems with modern websites? The answer was yes. We dont need a world filled with IE3 and Netscape Navigator any more, anymore than we need encryption tools that provide a false sense of security. From micah at riseup.net Thu May 14 15:46:10 2009 From: micah at riseup.net (Micah Anderson) Date: Thu, 14 May 2009 09:46:10 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> Message-ID: <8763g34x25.fsf@pond.riseup.net> David Shaw writes: > I don't mean there are faster/easier/cheaper ways of doing this > mathematically. I mean boring old subterfuge like going to a > keysigning party with a fake ID, claiming to be someone else. I get a > bunch of signatures, and I'm done. It skips the whole difficult math > problem. > > I'm all for strong crypto protection against impersonation, but when > there is a non-crypto impersonation attack that has essentially the > same end result as a crypto impersonation attack, and the non-crypto > variant of the attack is vastly cheaper, faster, and easier than the > crypto attack, I do start to wonder what the point is of putting a > strong crypto defense against the crypto attack. That is very true, and I appreciate you pointing this out. However, this problem is a different problem that is not going to be solved by any amount of crypto or strong hashing algorithms (in fact I would argue that fixing social problems with technical solutions is always a dubious prospect). The problem that *can* be solved here is the technical one, and holding back that solution because there is a weaker link in the chain that the gnupg OpenPGP implementation cannot solve doesn't seem like the right answer to me. In fact, I'd argue that the human element is always going to be the weaker link and always has been. Taking this position, I wonder why we don't consider saving some CPU cycles and step back the crypto, maybe even reverting to ROT13 because even that is tedious and difficult for a human to do, when its probably easier to send some cash off to the Transnational Republic to get a decent looking identification. > Certainly. This is the sort of thing that reasonable people can > disagree on. I don't think that your plan is wrong or evil or > anything like that. I just worry it's rather eager to expunge SHA-1. > The plan pushes a 3-month window to migrate to SHA-256 and revoke all > earlier keys. We're not particularly close to having any collision at > all, much less the finesse necessary to "weaponize" that collision > generating process into an attack on OpenPGP. I had a slightly different read of this plan than you did and I think that subtlety is a source of the resistance here. My understanding was that this plan was suggesting that the people (Debian Developers) who make up the largest strongly connected set in the existing Web of Trust, begin considering a transition. This seems a lot different from what I am gathering was your reading, which seems to suggest that there be a 3-month window to expunge SHA-1 entirely from the universe. The timeline that I see detailed is much more conservative than that, instead it seems to describe a timeline that is for an individual who, after careful consideration, has decided to go through a key transition. The timeline is based on an evaluation of the timeline that the author went through when he did a transition. In fact the whole document is couched in words like "prepare", "consider", "move in an orderly fashion", "eventual", "carefully", etc. I do not get the aggressive push, or the 3-month timeline that you seem to have read from the plan. The author seems to understand that we are not close to having a "weaponized" collision, but that it eventually will be coming so we need to start thinking proactively, instead of getting caught with our collective MD5 pants down (c.f. RapidSSL) > There are a good number of ways to shoot yourself in the foot with > GPG, and I've seen a good few of them in the past week or so. I I would like to know what these foot shots are, as I am sure other people (especially in the comments of that blog post) would. You mention the interoperability with software from 5 years ago as a potential problem, can you detail some more of the others you've seen? micah From rjh at sixdemonbag.org Sat May 16 05:43:42 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 May 2009 23:43:42 -0400 Subject: SHA-1 recommendations Message-ID: <4A0E366E.7030601@sixdemonbag.org> I've been a bit drowned by work, but I've had the opportunity lately to draw up that list of recommendations I was threatening to inflict on people. :) http://secret-alchemy.com/sha1 Comments and constructive feedback are welcome. If there's interest, then let's hammer out where it's deficient and what language needs to be cleaned up, then get a final draft out, and start getting people in the community to provide detached sigs for the page. From wk at gnupg.org Sun May 17 14:00:40 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 17 May 2009 14:00:40 +0200 Subject: RSA+RSA is now the default Message-ID: <87zldcszvb.fsf@wheatstone.g10code.de> Hi! I just committed changes to the GnuPG trunk to make RSA with an RSA subkey the default. This also changes the order of the presented algorithms, but 1 is still the default. The interactive --gen-key has never been intended for use by frontends, thus this change may only reveal buggy frontends ;-). Frontends should use the --batch key generation with a parameter file and thus need to change the default algorithm on their own (I already did this for GPA). Here is the new prompt in standard mode: $ gpg2 -v --gen-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. [...] and here in expert mode which allows to select the subkey size: $ gpg2 -v --gen-key --expert Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits RSA keys may be between 1024 and 4096 bits long. What keysize do you want for the subkey? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. [...] I hope this is okay. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Sun May 17 14:07:59 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 17 May 2009 14:07:59 +0200 Subject: Make --enable-dsa2 the default? Message-ID: <87vdo0szj4.fsf@wheatstone.g10code.de> Hi! Now that GnuPG key generation defaults to RSA keys, we may want to make the option --enable-dsa2 the default. The man page currently reads: @item --enable-dsa2 @itemx --disable-dsa2 Enables new-style DSA keys which (unlike the old style) may be larger than 1024 bit and use hashes other than SHA-1 and RIPEMD/160. Note that very few programs currently support these keys and signatures from them. Folks not using the default parameters for a new key can be expected to know what they are doing and thus --enable-dsa2 should not get into their way. There will be warning anyway. Opinions? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From lion at lion.leolix.org Sun May 17 15:38:32 2009 From: lion at lion.leolix.org (Philipp Schafft) Date: Sun, 17 May 2009 15:38:32 +0200 Subject: Make --enable-dsa2 the default? In-Reply-To: <87vdo0szj4.fsf@wheatstone.g10code.de> References: <87vdo0szj4.fsf@wheatstone.g10code.de> Message-ID: <20090517133838.EB63F7B201@priderock.keep-cool.org> reflum, On Sun, 2009-05-17 at 14:07 +0200, Werner Koch wrote: > Hi! > > Now that GnuPG key generation defaults to RSA keys, we may want to make > the option --enable-dsa2 the default. The man page currently reads: > [...] > Folks not using the default parameters for a new key can be expected to > know what they are doing and thus --enable-dsa2 should not get into > their way. There will be warning anyway. > > Opinions? wouldn't that also change the behavor on old 1024 bit DSA keys? If I upgrade to a newer GnuPG and have for example set SHA256 as default (for example with a RSA signing subkey) digest wouldn't that result the SHA256 cert sigs as well with all known problems? -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: This is a digitally signed message part URL: From dshaw at jabberwocky.com Sun May 17 19:26:22 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 May 2009 13:26:22 -0400 Subject: Make --enable-dsa2 the default? In-Reply-To: <87vdo0szj4.fsf@wheatstone.g10code.de> References: <87vdo0szj4.fsf@wheatstone.g10code.de> Message-ID: <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> On May 17, 2009, at 8:07 AM, Werner Koch wrote: > Hi! > > Now that GnuPG key generation defaults to RSA keys, we may want to > make > the option --enable-dsa2 the default. The man page currently reads: > > @item --enable-dsa2 > @itemx --disable-dsa2 > Enables new-style DSA keys which (unlike the old style) may be larger > than 1024 bit and use hashes other than SHA-1 and RIPEMD/160. Note > that very few programs currently support these keys and signatures > from them. > > Folks not using the default parameters for a new key can be expected > to > know what they are doing and thus --enable-dsa2 should not get into > their way. There will be warning anyway. I am cautiously in favor of this, but note this can change the behavior of existing 1024-bit (i.e. old) DSA keys also. If, for example, the user has set personal-digest-preferences to SHA256, then a truncated SHA256 will be used. It is true, though, that this will only happen in cases where the user has changed the defaults (as personal-digest-preference defaults to SHA1). David From dkg at fifthhorseman.net Sun May 17 23:44:49 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 17 May 2009 17:44:49 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A0E366E.7030601@sixdemonbag.org> References: <4A0E366E.7030601@sixdemonbag.org> Message-ID: <4A108551.1070207@fifthhorseman.net> On 05/15/2009 11:43 PM, Robert J. Hansen wrote: > http://secret-alchemy.com/sha1 > > Comments and constructive feedback are welcome. Thanks for writing this up, Robert. A few thoughts: Section 3.1: As much as i'd love to see X.509 go away for a variety of reasons, i'm not sure that saying "consider X.509 deprecated" is a realistic recommendation on today's network. I'm also not sure that X.509 really cannot handle more stronger digest algorithms. For example RFC 4055 (from June 2005) appears to list SHA-2 algorithms for X.509: http://tools.ietf.org/html/rfc4055#section-2.1 I could well be misinterpreting this, though. Could you provide some references for the claim? NSS, GnuTLS, and OpenSSL (three free TLS implementations with embedded X.509 certificate handling) all seemed comfortable with certificates and requests which use the SHA-2 family in my (currently unpublished) testing this past week. Section 3.2 Your 30-day timeframe for abandoning all 1024-bit DSA certificates seems quite aggressive. I proposed 90 days in my earlier document (and did a 90 day transition myself two years ago, which was a very comfortable timeline). I've seen other reasonable people propose 6 month transitions. Section 3.2.2.1 I think the proposed gpg.conf should also have "cert-digest-algo SHA256" if people want to make sure their certifications (i.e. signatures made over key+uid pairs) all use a stronger digest. Without that setting, certificates will continue to be made with SHA-1. I also think it's worth recommending an updated default-preference-list, as recent versions of gpg default to SHA1 SHA256 RIPEMD160, which is then embedded in the generated self-signatures and published. Unfortunately, I don't see an easy UI step to help people adjust their proclaimed digest preferences without also resetting their proclaimed cipher and compression preferences, which makes this step a bit clunky. Also in this section: it might be good to provide a link to evidence to support the claim that RIPEMD160 is "somewhat stronger" than SHA1. My impression was that it simply has not been the target of such heavy scrutiny. I think it's also worth explicitly recommending that the above configuration changes be made *before* generating a new key, so that the specified changes affect the new key itself. That's all the suggestions i've got for now. Let me know if any of the above doesn't make sense. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon May 18 00:27:31 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 17 May 2009 18:27:31 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A108551.1070207@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> Message-ID: <4A108F53.7000601@sixdemonbag.org> Daniel Kahn Gillmor wrote: > I'm also not sure that X.509 really cannot handle more stronger > digest algorithms. For example RFC 4055 (from June 2005) appears to > list SHA-2 algorithms for X.509: I was not aware of RFC 4055. Judging from some of the talk on ietf-openpgp, many people there are not aware of it, either. In light of this, the text should definitely be changed; thank you. > Section 3.2 > > Your 30-day timeframe for abandoning all 1024-bit DSA certificates > seems quite aggressive. Yes, by design. I think the likelihood of people completing a process decreases exponentially with the length of the process. 30 days is the most aggressive schedule I can think of that could still be considered reasonable enough to give correspondents an opportunity to raise objections, questions, etc., and get answers. If there's a consensus that we should make this a 90-day or 180-day process, I'll certainly change the text. That said, I think we should err on the side of an aggressive schedule. > I think the proposed gpg.conf should also have "cert-digest-algo > SHA256" if people want to make sure their certifications (i.e. > signatures made over key+uid pairs) all use a stronger digest. > Without that setting, certificates will continue to be made with > SHA-1. I am generally not a fan of altering this setting. This will cripple interoperability with other OpenPGP applications that do not support SHA256 in certifications. Again, though, if the consensus is for something different, I'll change the text. > I also think it's worth recommending an updated > default-preference-list, as recent versions of gpg default to SHA1 > SHA256 RIPEMD160, which is then embedded in the generated > self-signatures and published. This goes back to an old argument I've had with David Shaw, over whether the preference list is really a preference list at all. I don't see anything in RFC4880 which requires algorithms earlier in the list to be preferred over algorithms later in the list. (13.2 explicitly says it's an 'ordered list', which seems to imply it should be this way; however, a couple of paras later it says, 'the implementation may use any mechanism to pick an algorithm in the intersection [of the sender's and recipient's preferences]', which seems to strongly imply it's not the case, and a random selection would still be perfectly conformant.) If the preference list is really a capability set, then default-preference-list is fine as-is. We prefer to use SHA256, we advertise we can use SHA256, there's no problem. Even if the preference list is viewed as a preference list, default-preference-list is irrelevant. It only advertises to senders what algorithms we prefer. There is no requirement senders give us SHA-1 signed traffic, and senders should be set up to prefer SHA256. > Also in this section: it might be good to provide a link to evidence > to support the claim that RIPEMD160 is "somewhat stronger" than SHA1. > My impression was that it simply has not been the target of such > heavy scrutiny. You're correct. There are no significant attacks on RIPEMD-160, while there are on SHA-1. This means that at present RIPEMD-160 is believed somewhat stronger. Just how much stronger depends on how resistant RIPEMD-160 will be to the SHA-1 attacks -- and we really can't say that at present. My suspicion is it will not turn out to be very resistant. > I think it's also worth explicitly recommending that the above > configuration changes be made *before* generating a new key, so that > the specified changes affect the new key itself. This only seems necessary if we use cert-digest-algo. If we skip that, this seems unnecessary. From dkg at fifthhorseman.net Mon May 18 02:36:07 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 17 May 2009 20:36:07 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A108F53.7000601@sixdemonbag.org> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> Message-ID: <4A10AD77.8090904@fifthhorseman.net> On 05/17/2009 06:27 PM, Robert J. Hansen wrote: > Daniel Kahn Gillmor wrote: >> I think the proposed gpg.conf should also have "cert-digest-algo >> SHA256" if people want to make sure their certifications (i.e. >> signatures made over key+uid pairs) all use a stronger digest. >> Without that setting, certificates will continue to be made with >> SHA-1. > > I am generally not a fan of altering this setting. This will cripple > interoperability with other OpenPGP applications that do not support > SHA256 in certifications. Again, though, if the consensus is for > something different, I'll change the text. This is a difficult tradeoff. Certifications themselves seem to be the most likely place in the whole OpenPGP architecture where a keyholder will be signing material that is provided by a potential adversary. For example, if i meet Alice at a keysigning party, Alice provides me with a large chunk of fairly opaque data (her public key material, maybe possible to use as a carrier for collision-specific perturbations?), one or more User IDs (textual, more difficult to hide perturbations in), and zero or more user attributes (JPEGs, which i think are relatively simple to perturb in ways that the signer can't be reasonably expected to detect). I'm expected to issue one signature per UID (over key+uid) and per UAT (over key+uat), and the bitstream for each of these signatures is entirely specified by Alice. I can add subpackets to the hashing context *after* the material specified by Alice after i've signed it. But if Alice has found a collision, and her key+uat is "part A" of the collision, she can just append my provided subpackets to "part B" to preserve the digest collision. This makes me tend to concur with David Shaw we should stop making signatures over SHA-1 now: http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025048.html Which is why i suggested the cert-digest-algo. > If the preference list is really a capability set, then > default-preference-list is fine as-is. We prefer to use SHA256, we > advertise we can use SHA256, there's no problem. If it's a capability list, it's currently incorrectly set because the OpenPGP client used by the keyholder (gpg, in this case), has many more capabilities than those listed, including the longer digests in the SHA-2 family. If it's an ordered list of preferences, i think it's incorrectly set because we should be advertising our preference for stronger digests above SHA-1. Either way, i think it should be addressed in these guidelines. >> I think it's also worth explicitly recommending that the above >> configuration changes be made *before* generating a new key, so that >> the specified changes affect the new key itself. > > This only seems necessary if we use cert-digest-algo. If we skip that, > this seems unnecessary. It's relevant if either cert-digest-algo or default-preference-list is modified: the former affects the digest used to issue the self-sig, and the latter affects the embedded pref-hash-algos subpacket in the self-sig. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon May 18 03:06:08 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 17 May 2009 21:06:08 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A10AD77.8090904@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> Message-ID: <4A10B480.4050907@sixdemonbag.org> Daniel Kahn Gillmor wrote: > This is a difficult tradeoff. Certifications themselves seem to be the > most likely place in the whole OpenPGP architecture where a keyholder > will be signing material that is provided by a potential adversary. I don't share in this assessment. Digital signatures already enjoy the force of law in many jurisdictions; the hold-up is digital signature adoption, not legal. If/as digital signatures become more widespread, the possibility for document fraud via signature forgery increases. If you sign Alice's key at a keysigning party and then she uses that signature on a different UID/cert, you can dust off Alice's original key and say, "look, there are two identical sigs, Alice is up to something." The keyservers don't forget: they preserve Alice's original key. Compare this to a script that automatically signs documents -- a trusted timestamp, for instance. The script may not retain copies of documents it's seen or signatures it's made. That means if someone forges that timestamp signature, the only way to prove there's a forgery is to find the original document which was signed. That's a much dicier proposition. Predicting future attack vectors is easy; prioritizing them is incredibly difficult. I don't know what the most likely avenue of future attack will be, and am not persuaded that certifications seem to be the most likely place where a keyholder will be signing material provided by a potential adversary. My trusted timestamp example is a simple one: I'm sure if I were to think for a couple of hours I could come up with much more subtle and pernicious ones. That said, I agree with David's assessment that we need to migrate away from using SHA-1 for cert signatures. I just don't think that now is the right time to do it. I'd like to have some confidence that this will not create an interoperability nightmare. >> If the preference list is really a capability set, then >> default-preference-list is fine as-is. We prefer to use SHA256, we >> advertise we can use SHA256, there's no problem. > > If it's a capability list, it's currently incorrectly set Not at all. It can only be incorrectly set if the certificate advertises capabilities it doesn't possess. If I tell you, "I can handle SHA-1," that's a true statement of my capabilities even if I can handle SHA512, SHA384, SHA256, SHA224, RIPEMD160, MD5 and SHA-1. I believe it is a capability set, but there is nothing in the spec which requires it to be a _complete_ capability set. > If it's an ordered list of preferences, i think it's incorrectly set > because we should be advertising our preference for stronger digests > above SHA-1. As mentioned above, since I think it's a cap set, this is a non-issue. Other people may think differently, of course. > It's relevant if either cert-digest-algo or default-preference-list is > modified: the former affects the digest used to issue the self-sig, and > the latter affects the embedded pref-hash-algos subpacket in the self-sig. I'm not phrasing things in terms of logical clauses to be difficult; I'm doing things this way for clarity. Hopefully they can shed some light on my position. Relevant := Modified(cert-digest-algo) || (Modified(default-preference-list) && IsPrefList(default-preference-list)) Modified(cert-digest-algo) = False Modified(digest-preference-list) = True IsPrefList(default-preference-list) = False Relevant := False || (True && False) Relevant := False || False Relevant := False If you believe the list is a pref list, you will come to a different evaluation of the relevancy than I do. Hopefully this clarifies where I stand on the relevancy issue. From dshaw at jabberwocky.com Mon May 18 04:20:16 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 May 2009 22:20:16 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A10AD77.8090904@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> Message-ID: <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> On May 17, 2009, at 8:36 PM, Daniel Kahn Gillmor wrote: > This is a difficult tradeoff. Certifications themselves seem to be > the > most likely place in the whole OpenPGP architecture where a keyholder > will be signing material that is provided by a potential adversary. > > For example, if i meet Alice at a keysigning party, Alice provides me > with a large chunk of fairly opaque data (her public key material, > maybe > possible to use as a carrier for collision-specific perturbations?), > one > or more User IDs (textual, more difficult to hide perturbations in), > and > zero or more user attributes (JPEGs, which i think are relatively > simple > to perturb in ways that the signer can't be reasonably expected to > detect). I would wager that IF an OpenPGP certification specific SHA-1 collision attack eventually appears, it would appear for photo IDs first. There are a huge number of ways to twiddle bits in a JPEG (the thing supports *comment fields* for crying out loud) in ways that aren't visible in the image itself. Incidentally, I don't sign photo IDs. It has nothing to do with this theoretical attack - a photo ID does not make a statement that I am willing to certify. > I'm expected to issue one signature per UID (over key+uid) and per UAT > (over key+uat), and the bitstream for each of these signatures is > entirely specified by Alice. I can add subpackets to the hashing > context *after* the material specified by Alice after i've signed it. > But if Alice has found a collision, and her key+uat is "part A" of the > collision, she can just append my provided subpackets to "part B" to > preserve the digest collision. > > This makes me tend to concur with David Shaw we should stop making > signatures over SHA-1 now: > > http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025048.html I do think that people should stop issuing SHA-1 certifications, but there are other considerations that need to be taken into account here - not all clients can handle those signatures, and I don't think we're at the point where defaults should be changed. It's not a black or white situation. So, while I personally am issuing SHA-256 key certifications (and have been for a while), I do not think that switching the default away from SHA-1 is appropriate at this time. What is good for me is not necessarily what is good for the whole world. >> If the preference list is really a capability set, then >> default-preference-list is fine as-is. We prefer to use SHA256, we >> advertise we can use SHA256, there's no problem. > > If it's a capability list, it's currently incorrectly set because the > OpenPGP client used by the keyholder (gpg, in this case), has many > more > capabilities than those listed, including the longer digests in the > SHA-2 family. > > If it's an ordered list of preferences, i think it's incorrectly set > because we should be advertising our preference for stronger digests > above SHA-1. I see no conflict in the RFC: the list is ordered, and a random selection is perfectly conformant. The list is ordered to give implementations that want to do something useful with rankings something to work with (and note that both of the "big two" of PGP and GPG order their lists to varying degrees), but those implementations that do not want to play with rankings are allowed to pick however they like. It's similar, in a way, to the IETF meta-rule: be conservative in what you generate, be liberal in what you accept. So it's an ordered list of capabilities. Or perhaps a capability set of preferences. ;-) David From wk at gnupg.org Mon May 18 08:34:06 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2009 08:34:06 +0200 Subject: [PATCH] Caching symmetric encryption passphrase with gpg-agent In-Reply-To: (Daiki Ueno's message of "Sat, 09 May 2009 19:02:17 +0900") References: <87ab5o7x3z.fsf@broken.deisui.org> Message-ID: <87eium7wdd.fsf@wheatstone.g10code.de> Hi! I applied the patch. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon May 18 07:15:30 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2009 07:15:30 +0200 Subject: Make --enable-dsa2 the default? In-Reply-To: <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> (David Shaw's message of "Sun, 17 May 2009 13:26:22 -0400") References: <87vdo0szj4.fsf@wheatstone.g10code.de> <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> Message-ID: <87ws8f6lfx.fsf@wheatstone.g10code.de> On Sun, 17 May 2009 19:26, dshaw at jabberwocky.com said: > I am cautiously in favor of this, but note this can change the > behavior of existing 1024-bit (i.e. old) DSA keys also. If, for Right, I checked this yesterday. Thus you mean we shall wait for that change a little bit longer? I would be fine with that too. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon May 18 08:04:43 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 May 2009 08:04:43 +0200 Subject: [PATCH] Make update_keysig_packet honour cert-digest-algo In-Reply-To: <871vqr4usq.fsf@pond.riseup.net> (Micah Anderson's message of "Thu, 14 May 2009 10:35:01 -0400") References: <4A06EE8D.9030504@cruicky.co.uk> <4A09922C.9050100@fifthhorseman.net> <3539AA81-036C-490D-B7DB-E56E9DD2AED4@jabberwocky.com> <4A09A905.4040205@fifthhorseman.net> <4DE9E9F5-C136-444B-B620-030C42B9D89F@jabberwocky.com> <4A09D676.8030307@fifthhorseman.net> <87ljp1xiy3.fsf@wheatstone.g10code.de> <871vqr4usq.fsf@pond.riseup.net> Message-ID: <87skj36j5w.fsf@wheatstone.g10code.de> On Thu, 14 May 2009 16:35, micah at riseup.net said: > discussion is helpful. However, the first sentence of what you said was > grounded in reality, but then you immediately stepped into > speculation. You are right that 'maybe it will be possible to mount a Predicting the future is always speculation. My point is that from an attackers point of view there are far easier attack vectors than the use of any kind of modern cryptanalysis. We need to keep this in mind when talking about the *immediate* need to change algorithms. > The reality here is the following: the reduction in keyspace travel > could point to a trend similar to what happened with MD-5 (ie. further By the time we started the OpenPGP WG in fall 1997 it was already known that MD5 had severe weaknesses. Thus PGP5 and thus OpenPGP used the best hash algorithm available at that time: SHA-1. We knew that it would not last forever and that SHA-1 doesn't match the strength of the other algorithms; we eagerly waited for the SHA-2 series of algorithms to get released by the NSA. It is 6 years since we implemented them and only now we can be somewhat sure that they are widely available. Thus we are now discussing how to make use of them. Deploying a new algorithm takes time, a lot of time. Peter Gutmann has a paper on this topic. We, the OpenPGP community, are quite good in deploying new algorithms - way faster than other groups. > what does the gnupg development need to think about? I don't want to > claim that interoperability is not important, but I do think that gnupg, > as the flagship free OpenPGP implementation, should take the responsible > lead and push the Web of Trust to do the right thing. GnuPG already We are doing exactly this. Deploying a code base which allows to use newer algorithms without to much hassles. This all started 6 years ago with SHA-2, now continues by changing the default algorithms for new keys and will eventually deprecate the default use of SHA-1 and DSA-1024. > right now (if you ignore the fact that collisions in the key space are > now within the reach of Well Funded Organizations, which I personally do > not think is something that should be ignored in a cavalier > manner). Because there is no problem right now, we have the space to GnuPG has all features to use stronger algorithms; what we are discussing are the default algorithms for users who are not security experts and need something which just works and is secure enough for their use cases. > gracefully before it hit us. Lets actually plan for the future, instead > of deferring that planning. As said we are doing exactly this. We need to take some care because we don't want to fall into the X.509/CMS trap where it took more than a decade that the major applications achieved a little interoperability - on the least common denominator. > There are always going to be other weaknesses, but thats not an excuse > for gnupg to not try to be better. All of these things need to be Right, I listed them to show that it is much harder to deploy secure systems than just replacing an algorithm. > improved, but doing so is not the role of gnupg. This list is for gnupg > development, not a list about Windows security, or whatever. Each one of It is not about Windows. Windows is not worse than other major OSes. Code quality is a major problem and unfortunately one which can't be solved as "easily" as creating a more secure algorithm. > I may be an outlier here, but those 5-year old programs that will have > interoperability problems are going to have other issues that > significantly reduce their security. We should not let old software that Maybe, we don't know. GNU/Linux distributions usually keep on fixing security bugs even for very old software. GnuPG 1.2 reached end of life a bit more that 4 years ago but it is still widely enough in use. We even did a security update on our own 2 years after end of life. Those who really need state of the art security will use a more recent version. The default key sizes are not a problem for them and they can cope with possible interop problems. > At some point Firefox was also faced with this decision: should they > push for a better web, knowing that they will cause the older browsers Supporting EV certificates for a better web? I beg to differ; they are merely shoveling more coal into the the big certificate vending machine. . Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon May 18 15:24:25 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 09:24:25 -0400 Subject: Make --enable-dsa2 the default? In-Reply-To: <87ws8f6lfx.fsf@wheatstone.g10code.de> References: <87vdo0szj4.fsf@wheatstone.g10code.de> <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> <87ws8f6lfx.fsf@wheatstone.g10code.de> Message-ID: On May 18, 2009, at 1:15 AM, Werner Koch wrote: > On Sun, 17 May 2009 19:26, dshaw at jabberwocky.com said: > >> I am cautiously in favor of this, but note this can change the >> behavior of existing 1024-bit (i.e. old) DSA keys also. If, for > > Right, I checked this yesterday. Thus you mean we shall wait for that > change a little bit longer? I would be fine with that too. I wonder if the ideal change would be to remove the --enable-dsa2 block on new keys, but leave it in place in general. That would mean that new q>160 keys could be generated (with a warning), and these keys could use whatever hash was appropriate for them, but existing q==160 keys would still be locked to SHA-1 or RIPEMD/160. I'm okay with just waiting for a while longer, too. David From dkg at fifthhorseman.net Mon May 18 17:14:17 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 May 2009 11:14:17 -0400 Subject: SHA-1 recommendations In-Reply-To: <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> Message-ID: <4A117B49.5090200@fifthhorseman.net> On 05/17/2009 10:20 PM, David Shaw wrote: > I would wager that IF an OpenPGP certification specific SHA-1 collision > attack eventually appears, it would appear for photo IDs first. There > are a huge number of ways to twiddle bits in a JPEG (the thing supports > *comment fields* for crying out loud) in ways that aren't visible in the > image itself. This does seem ripe for attack. > Incidentally, I don't sign photo IDs. It has nothing to do with this > theoretical attack - a photo ID does not make a statement that I am > willing to certify. I've always assumed that a User Attribute of a jpeg is semantically interpreted as a visual representation of the keyholder, by analogy to the photo in a passport, driver's license, or other official documentation. It basically says " looks like this:". This can change a fair amount (hair changes, age, accidents, body modifications, odd lighting, etc make images far more fluid than UTF-8 name designations), so I can understand not being willing to make a long-lived certification like this. But i don't think it invalidates the concept. (as an aside, this does make me particularly wary of people who sign photo IDs like the one attached to F1530A35) > I do think that people should stop issuing SHA-1 certifications, but > there are other considerations that need to be taken into account here - > not all clients can handle those signatures, and I don't think we're at > the point where defaults should be changed. It's not a black or white > situation. > > So, while I personally am issuing SHA-256 key certifications (and have > been for a while), I do not think that switching the default away from > SHA-1 is appropriate at this time. What is good for me is not > necessarily what is good for the whole world. Understood. We're not discussing changing the defaults here, though, we're discussing Robert J. Hansen's proposed document for people who are interested in mitigating whatever risks may be implied by a progressive weakening of SHA-1. Out of curiosity: how do you propose deciding when to change the default certificate digest algorithm? I understand that there are interoperability concerns, many of which i'm personally less directly affected by because of my involvement with the free software development community, which tends to have a quicker (if not smoother) upgrade path. Can we characterize those concerns in some way to better understand what needs to change in the broader landscape before the defaults get changed? Should we ask PGP Corp (and any other vendors on ietf-openpgp) for their deployment estimates of PGP versions which do not support SHA-256? Is there a way that we can make reasonable estimations for the same count for GnuPG deployments? Here's an idea: trawl the public keyservers, and look at the proportion of valid (non-expired, non-revoked) keys with digest preference subpackets in their self-sigs which mention any digest from the SHA-2 family. It would be good to rule out abandoned keys somehow; doing so is probably fundamentally impossible, but maybe we could approximate it by discarding keys with no certifications attached in the last 5 years? Are there better metrics? > I see no conflict in the RFC: the list is ordered, and a random > selection is perfectly conformant. The list is ordered to give > implementations that want to do something useful with rankings something > to work with (and note that both of the "big two" of PGP and GPG order > their lists to varying degrees), but those implementations that do not > want to play with rankings are allowed to pick however they like. It's > similar, in a way, to the IETF meta-rule: be conservative in what you > generate, be liberal in what you accept. > > So it's an ordered list of capabilities. Or perhaps a capability set of > preferences. ;-) I'm not suggesting there is a conflict in the RFC, simply that it seems that GnuPG could use a refresh of its default digest preferences. I'm proposing (for new key generation): * include the stronger SHA-2 digests which gpg supports, and * re-order them in a clearly-stated way (i.e. commit to saying "gpg interprets and produces the orderings as preferential, with most-desired first"), and explicitly, publically prefer digests from the SHA-2 family over SHA-1. I don't see how this could cause interoperability problems or violate the RFC (as you say, other implementations are free to treat the list as random), and it would help users of gpg communicate to each other directly that they are happy to use the newer, stronger digests. Are there interop problems with doing this that i'm not aware of? The only thing i'd be worried about is if there are widespread implementations which explicitly interpret the list as "preferential orderings, *least*-desired first", but i don't think that's the case. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon May 18 17:38:26 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 May 2009 11:38:26 -0400 Subject: SHA-1 recommendations In-Reply-To: <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> Message-ID: <4A1180F2.5070808@fifthhorseman.net> On 05/17/2009 10:20 PM, David Shaw wrote: > I see no conflict in the RFC: the list is ordered, and a random > selection is perfectly conformant. i just re-read that bit of the RFC, and while it's somewhat vague, i think a reasonable interpretation is that it is indeed intended to be an ordered, exhaustive list of algorithms supported, with most-preferred algorithms listed first. The relevant bits are: >> 5.2.3.7. Preferred Symmetric Algorithms >> >> (array of one-octet values) >> >> Symmetric algorithm numbers that indicate which algorithms the key >> holder prefers to use. The subpacket body is an ordered list of >> octets with the most preferred listed first. It is assumed that only >> algorithms listed are supported by the recipient's software. >> Algorithm numbers are in Section 9. This is only found on a self- >> signature. >> >> 5.2.3.8. Preferred Hash Algorithms >> >> (array of one-octet values) >> >> Message digest algorithm numbers that indicate which algorithms the >> key holder prefers to receive. Like the preferred symmetric >> algorithms, the list is ordered. Algorithm numbers are in Section 9. >> This is only found on a self-signature. so pref-sym-algos is explicitly "most preferred listed first" and pref-hash-algos is ordered like pref-sym-algos. furthermore, pref-sym-algos says that "only algorithms listed are supported". This is different from "only supported algorithms are listed", and is equivalent to "algorithms not listed are not supported". Granted, the above distinction is only explicitly for pref-sym-algos, but it is not unreasonable to interpret 5.2.3.8 as implying the same thing ("Like the preferred symmetric algorithms..."). I think a strong case can be made *for* adjusting the default-preference-list to include the longer SHA-2 algos, and to order them first. Are there arguments against doing so? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon May 18 19:09:48 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 13:09:48 -0400 Subject: Signing photo IDs (was Re: SHA-1 recommendations) In-Reply-To: <4A117B49.5090200@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> Message-ID: <3BC98B16-C069-41FF-9882-FCEDA342D410@jabberwocky.com> (Split off from the earlier thread, as the topic has drifted) On May 18, 2009, at 11:14 AM, Daniel Kahn Gillmor wrote: >> Incidentally, I don't sign photo IDs. It has nothing to do with this >> theoretical attack - a photo ID does not make a statement that I am >> willing to certify. > > I've always assumed that a User Attribute of a jpeg is semantically > interpreted as a visual representation of the keyholder, by analogy to > the photo in a passport, driver's license, or other official > documentation. It basically says " looks like this:". > This > can change a fair amount (hair changes, age, accidents, body > modifications, odd lighting, etc make images far more fluid than UTF-8 > name designations), so I can understand not being willing to make a > long-lived certification like this. But i don't think it invalidates > the concept. I'm not saying the concept is invalid. Just that I personally don't find it compelling enough to sign. A user ID string says at least two useful things about the keyholder: a) their real-world name, and b) how they can be reached (i.e. their email). Many people don't bother to check (b), which I find silly - taking some non-zero effort to verify the first half of the user ID (by looking at drivers licenses, etc) but no effort at all to check the second half? A photo is a different sort of thing altogether. While a name+email makes a reasonably strong binding between a real person and a key, a photo doesn't. That would be certifying them (and in practice making their key become valid) because I think they resemble a photo. > (as an aside, this does make me particularly wary of people who sign > photo IDs like the one attached to F1530A35) Maybe he really does look like that... David From dshaw at jabberwocky.com Mon May 18 19:21:27 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 13:21:27 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A117B49.5090200@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> Message-ID: <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> On May 18, 2009, at 11:14 AM, Daniel Kahn Gillmor wrote: >> So, while I personally am issuing SHA-256 key certifications (and >> have >> been for a while), I do not think that switching the default away >> from >> SHA-1 is appropriate at this time. What is good for me is not >> necessarily what is good for the whole world. > > Understood. We're not discussing changing the defaults here, though, > we're discussing Robert J. Hansen's proposed document for people who > are > interested in mitigating whatever risks may be implied by a > progressive > weakening of SHA-1. Understood, but I believe the quote from me that was used was from that context, so I wanted to make that context clear. I don't really favor this sort of "here's how to transition everyone" document. > Here's an idea: trawl the public keyservers, and look at the > proportion > of valid (non-expired, non-revoked) keys with digest preference > subpackets in their self-sigs which mention any digest from the SHA-2 > family. It would be good to rule out abandoned keys somehow; doing so > is probably fundamentally impossible, but maybe we could approximate > it > by discarding keys with no certifications attached in the last 5 > years? Not all users of OpenPGP use the keyservers or even participate in the web of trust. It's also used in various environments where keys are traded manually. >> I see no conflict in the RFC: the list is ordered, and a random >> selection is perfectly conformant. The list is ordered to give >> implementations that want to do something useful with rankings >> something >> to work with (and note that both of the "big two" of PGP and GPG >> order >> their lists to varying degrees), but those implementations that do >> not >> want to play with rankings are allowed to pick however they like. >> It's >> similar, in a way, to the IETF meta-rule: be conservative in what you >> generate, be liberal in what you accept. >> >> So it's an ordered list of capabilities. Or perhaps a capability >> set of >> preferences. ;-) > > I'm not suggesting there is a conflict in the RFC, simply that it > seems > that GnuPG could use a refresh of its default digest preferences. No, I was agreeing with you. Robert saw a conflict, but I don't. > * include the stronger SHA-2 digests which gpg supports, and > > * re-order them in a clearly-stated way (i.e. commit to saying "gpg > interprets and produces the orderings as preferential, with most- > desired > first"), and explicitly, publically prefer digests from the SHA-2 > family > over SHA-1. I don't have a problem with this. GPG does interpret the ordering as preferential (is there some source that says otherwise?). The current default hash preference list is "SHA1 SHA256 RIPEMD160". It's simple enough to juggle the list so that SHA256 comes first, etc. I wouldn't want to put that into some extra document, though: it's a fairly small, and quite safe change. I'd support changing the default for that. David From dshaw at jabberwocky.com Mon May 18 19:31:32 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 13:31:32 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A1180F2.5070808@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A1180F2.5070808@fifthhorseman.net> Message-ID: <170ADF42-1306-41D0-BAC7-DDF85D90F0E6@jabberwocky.com> On May 18, 2009, at 11:38 AM, Daniel Kahn Gillmor wrote: > On 05/17/2009 10:20 PM, David Shaw wrote: >> I see no conflict in the RFC: the list is ordered, and a random >> selection is perfectly conformant. > > i just re-read that bit of the RFC, and while it's somewhat vague, i > think a reasonable interpretation is that it is indeed intended to > be an > ordered, exhaustive list of algorithms supported, with most-preferred > algorithms listed first. The relevant bits are: I agree with you, except for the "exhaustive" part. I see no wording that states or even suggests that all possible algorithms supported need to be listed. I list algorithms that I like, in the order in which I like them. That's it. If I leave an algorithm off, that means either I don't like it or it doesn't exist in my implementation. For example, I'm running a recent GPG, so I could have any combination of 3DES, CAST5, BLOWFISH, AES, AES192, AES256, and TWOFISH. If I was to make a brand new key, I'd probably just list AES and 3DES (and maybe Camellia). I don't "prefer" the others. David From dkg at fifthhorseman.net Mon May 18 19:49:37 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 May 2009 13:49:37 -0400 Subject: SHA-1 recommendations In-Reply-To: <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> Message-ID: <4A119FB1.2060202@fifthhorseman.net> On 05/18/2009 01:21 PM, David Shaw wrote: > Understood, but I believe the quote from me that was used was from that > context, so I wanted to make that context clear. I don't really favor > this sort of "here's how to transition everyone" document. I think that Robert started the document in an attempt to address your earlier concern that there was a lot of bad advice floating around on the 'net: http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025054.html Are you saying that you think such a document is a bad idea in general, and you'd never consider endorsing such a thing? Is there a better way to address the legitimate concern you've raised? > Not all users of OpenPGP use the keyservers or even participate in the > web of trust. It's also used in various environments where keys are > traded manually. True. For those who do not participate in the WoT, the choice of cert-digest-algo is irrelevant, though (they don't interpret certificates at all), so we can ignore those people in this consideration. For people who do use the WoT, but exchange keys manually or don't use the public keyserver network, i don't have a proposal for how to account for them. Do you? I'm trying to understand when we'll know that it's ok to switch the defaults. At the moment, the decision seems to be based on hunches/speculation about what kind of cryptanalytic attacks are possible and the distribution of deployed tools. Both of these data points are hazy at best, and how we make the tradeoff between the two is unclear as well. It would be nice to have some more-concrete target or rationale that we could use to judge when to make this transition. I was proposing a metric not because i thought it captured everything, but because it seemed *more* grounded in reality than my current hunches. I'd be happy to see a better metric proposed, or an explicit timeline based on the current best guesses. >> * include the stronger SHA-2 digests which gpg supports, and >> >> * re-order them in a clearly-stated way (i.e. commit to saying "gpg >> interprets and produces the orderings as preferential, with most-desired >> first"), and explicitly, publically prefer digests from the SHA-2 family >> over SHA-1. > > I don't have a problem with this. GPG does interpret the ordering as > preferential (is there some source that says otherwise?). The current > default hash preference list is "SHA1 SHA256 RIPEMD160". It's simple > enough to juggle the list so that SHA256 comes first, etc. I wouldn't > want to put that into some extra document, though: it's a fairly small, > and quite safe change. I'd support changing the default for that. OK, if that's a known assumption, i agree it doesn't need any sort of additional formal document. And i do think that gpg should change the default preference list to be (for digests only -- i'm haven't looked into ciphers enough to make a reasonable estimation): SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 I've left off MD5 even though gpg implements that digest algorithm in an attempt to indicate that it is actively deprecated. Any objections to changing this default? should i submit a patch? Getting this rolled into the version that produces new RSA+RSA key defaults would be nice, i think. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon May 18 20:04:44 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 May 2009 14:04:44 -0400 Subject: SHA-1 recommendations In-Reply-To: <170ADF42-1306-41D0-BAC7-DDF85D90F0E6@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A1180F2.5070808@fifthhorseman.net> <170ADF42-1306-41D0-BAC7-DDF85D90F0E6@jabberwocky.com> Message-ID: <4A11A33C.3060300@fifthhorseman.net> On 05/18/2009 01:31 PM, David Shaw wrote: > I agree with you, except for the "exhaustive" part. I see no wording > that states or even suggests that all possible algorithms supported need > to be listed. This is the line in question (split across pages in the RFC): It is assumed that only algorithms listed are supported by the recipient's software. i think you're reading this as: It is assumed that all algorithms listed are supported by the recipient's software. or even: Implementations generating these subpackets SHOULD only list algorithms which are supported by the implementation. but either of these modified versions change the meaning from a statement about the software to a statement about what is listed. If that was the original intent, maybe we should propose it during the next round of OpenPGP revisions? anyway, this is some trivial/arcane RFC lawyering, and the question for this list is what should be advertised by gpg. I'd say that good openpgp tools should prefer stronger digests when they support them, and should publicly advertise that fact, which is why i proposed the new ordering. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon May 18 20:16:23 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 14:16:23 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A11A33C.3060300@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A1180F2.5070808@fifthhorseman.net> <170ADF42-1306-41D0-BAC7-DDF85D90F0E6@jabberwocky.com> <4A11A33C.3060300@fifthhorseman.net> Message-ID: <4E069C1B-3F71-4898-8151-81502B2DEEFF@jabberwocky.com> On May 18, 2009, at 2:04 PM, Daniel Kahn Gillmor wrote: > On 05/18/2009 01:31 PM, David Shaw wrote: >> I agree with you, except for the "exhaustive" part. I see no wording >> that states or even suggests that all possible algorithms supported >> need >> to be listed. > > This is the line in question (split across pages in the RFC): > > It is assumed that only algorithms listed are supported by the > recipient's software. i.e. don't list it if you don't support it. Since both PGP and GPG managed to read it the same way, and there is also a discussion as to what happens if if an implementation gets a message using an algorithm it doesn't list (something that would not be possible if all algorithms were listed), I don't think there is all that much confusion in the community as to what this means. David From lists at lina.inka.de Mon May 18 20:54:45 2009 From: lists at lina.inka.de (Bernd Eckenfels) Date: Mon, 18 May 2009 20:54:45 +0200 Subject: SHA-1 recommendations In-Reply-To: <4E069C1B-3F71-4898-8151-81502B2DEEFF@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A1180F2.5070808@fifthhorseman.net> <170ADF42-1306-41D0-BAC7-DDF85D90F0E6@jabberwocky.com> <4A11A33C.3060300@fifthhorseman.net> <4E069C1B-3F71-4898-8151-81502B2DEEFF@jabberwocky.com> Message-ID: <20090518185445.GA20000@lina.inka.de> On Mon, May 18, 2009 at 02:16:23PM -0400, David Shaw wrote: > > It is assumed that only algorithms listed are supported by the > > recipient's software. > > i.e. don't list it if you don't support it. Well, my english understanding would read "only" as "not more than". This would be "It is assumed that no more then the listed algorithms are supported by the recipient's software". This sentence asks for an errata. And now matter how you read it, GPG should add prefered larger algorithms by default. Gruss Bernd -- (OO) -- Bernd_Eckenfels at M?rscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes at IRCNet v:+497211603874 f:+49721151516129 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From gerry.lowry at abilitybusinesscomputerservices.com Mon May 18 20:38:43 2009 From: gerry.lowry at abilitybusinesscomputerservices.com (gerry_lowry (alliston ontario canada)) Date: Mon, 18 May 2009 14:38:43 -0400 Subject: Signing photo IDs (was Re: SHA-1 recommendations) References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net><34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com><4A117B49.5090200@fifthhorseman.net> <3BC98B16-C069-41FF-9882-FCEDA342D410@jabberwocky.com> Message-ID: <28E6634E8C0F426CA38881CBC8E86404@zentrumvegan> I think I"m agreeing with David Shaw. My key has my photo. I'm the male between the two pictures of the lawyer Gerry Lowry at http://images.google.com/images?hl=en&q=gerrylowry&gbv=2&aq=f&oq=. (assuming the Google images you see are in the same order as I see now; that can change because Google is fluid). Problem is, since that picture was taken, I've lost weight. Also, I've glasses for reading and glasses for driving because I refuse to wear bifocals. So I may not look like my photo. Add to that the ability of professional make up artists to make people appear to be someone else and you get a bit of a political thriller movie aspect to the whole picture thing. Then, there's good old PhotoShop and similar software. So a picture is just not that reliable. What a picture does add, however, is another layer to the security onion. While this makes the picture valuable, it is of lesser value that a driver's license and a passport. Of greatest value are real people who are worthy of trust and actually have known you for a very long time. Brief encounters at a key signing party are useful but are also of questionable value. If I do not know you but I do know the person who signed your key and that person knows you well and will vouch for you, therein is great value. A worst case scenario is still possible: Bob's doctor, lawyer, dentist, and member of parliament have all signed Bob's key. Bob has 616 additional signatures from the 72 key signing parties that he's attended and hosted over the last 11.5 years. The is no doubt that Bob's signature is valid. Unfortunately, through the application of rubber hose cryptanalysis, Bob has revealed all prior to being embedded in concrete overshoes and sent to the bottom of a lake. gerry From rjh at sixdemonbag.org Tue May 19 00:19:37 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 May 2009 18:19:37 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A117B49.5090200@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> Message-ID: <4A11DEF9.3070509@sixdemonbag.org> Daniel Kahn Gillmor wrote: > Understood. We're not discussing changing the defaults here, though, > we're discussing Robert J. Hansen's proposed document for people who are > interested in mitigating whatever risks may be implied by a progressive > weakening of SHA-1. Please; in conversation, I'm just Rob. I have an unfortunate name, in that it's shared by a lot of famous people: Robert Hansen the serial killer, Robert Hanssen the Soviet spy, Robert Hansen the NBA All-Star, Robert Hansen the CEO of SecTheory... to make matters worse, I have tangential connections with almost all of them. I grew up near to where Robert Hansen the serial killer grew up, I was active on a couple of the same USENET groups as Robert Hanssen the spy, I attended the same college as Robert Hansen the NBA All-Star, both SecTheory Robert Hansen and I have spoken at some of the same conferences, etc., etc. Basically, if I don't go by my full name and middle initial, I tend to walk into identity misunderstandings that are straight out of _Twelfth Night_. > Can we characterize those concerns in some way to better understand > what needs to change in the broader landscape before the defaults get > changed? My own number one: PGP 6 needs to be abandoned. It's old, it's not especially standards-conformant (not surprising, given it predates the standard), and cert-digest-algo will break it. As will any hashes other than SHA-1, MD5 and RIPEMD160, for that matter. The installed base of PGP 6 users is immense, and many of them staunchly refuse to upgrade. So if we shift to SHA256 across the board, a lot of PGP 6 users will scream bloody murder that we're breaking traffic for them. OpenPGP has always been hobbled by its own success. The number one inhibitor of OpenPGP adoption has always been the tremendous success of PGP 2.6, which is still in use in lots of places. Once you come up with something that works and works well, you create tremendous inertia which resists the adoption of something new -- even if that something new is necessary. > Should we ask PGP Corp (and any other vendors on ietf-openpgp) for their > deployment estimates of PGP versions which do not support SHA-256? We could, but I don't think it would be productive. SHA256 has been supported since PGP 8, which is by this time more than a few years old. PGP 6 goes back all the way to, what, '97 -- people who are installing PGP 6 nowadays are doing it by getting copies from their friends, not by downloading it from PGP Corporation. AFAIK, PGP Corporation no longer makes PGP 6 available for download, and would much rather it just went away. They get to deal with the headache of the installed PGP 6 userbase just like we do. > * re-order them in a clearly-stated way (i.e. commit to saying "gpg > interprets and produces the orderings as preferential, with most-desired > first"), and explicitly, publically prefer digests from the SHA-2 family > over SHA-1. This would require a modification to the current code, which I would feel kind of bad about. I harped on the importance of considering the recipient's preferences for quite a while; finally, David was kind enough to change algorithm selection so that it works by a modified Borda count. We'd have to revisit that code, but I don't see as how it would be too difficult. I'd offer a patch, but I don't know what the GnuPG project's policy is on this -- some GNU projects frown on it for reasons of the headaches associated with copyright assignment. From rjh at sixdemonbag.org Tue May 19 00:32:45 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 May 2009 18:32:45 -0400 Subject: SHA-1 recommendations In-Reply-To: <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> Message-ID: <4A11E20D.8070109@sixdemonbag.org> David Shaw wrote: > No, I was agreeing with you. Robert saw a conflict, but I don't. Not so much a conflict as a let's-not-be-hasty. According to the spec, it must be an ordered preference list, but the other guy isn't required to treat it as anything other than a capability set. I understand GnuPG treats it as a preference list. I'm in favor of it being treated as a preference list. However, the other guy is free to interpret our preferences as being simply a capability set. This makes me think we should be cautious about assuming he will view them as a preflist: the spec explicitly allows him to treat it as a capset. I don't think this is very controversial, really. From rjh at sixdemonbag.org Tue May 19 00:37:07 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 May 2009 18:37:07 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A119FB1.2060202@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> <4A119FB1.2060202@fifthhorseman.net> Message-ID: <4A11E313.1000807@sixdemonbag.org> Daniel Kahn Gillmor wrote: > additional formal document. And i do think that gpg should change the > default preference list to be (for digests only -- i'm haven't looked > into ciphers enough to make a reasonable estimation): > > SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 I would be opposed to this, mostly for interop reasons. SHA256 is much more prevalent than SHA512 or SHA384. That said, it's pretty mild opposition: if the other guy doesn't advertise SHA512, it won't be used. From dshaw at jabberwocky.com Tue May 19 00:48:54 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 18:48:54 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A11E20D.8070109@sixdemonbag.org> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> <4A11E20D.8070109@sixdemonbag.org> Message-ID: On May 18, 2009, at 6:32 PM, Robert J. Hansen wrote: > David Shaw wrote: >> No, I was agreeing with you. Robert saw a conflict, but I don't. > > Not so much a conflict as a let's-not-be-hasty. According to the > spec, > it must be an ordered preference list, but the other guy isn't > required > to treat it as anything other than a capability set. > > I understand GnuPG treats it as a preference list. I'm in favor of it > being treated as a preference list. However, the other guy is free to > interpret our preferences as being simply a capability set. This > makes > me think we should be cautious about assuming he will view them as a > preflist: the spec explicitly allows him to treat it as a capset. > > I don't think this is very controversial, really. Nor I. I don't see that this makes any difference in practice for us: there is no harm in treating it as a preference list. If we rank the algorithms in order, and the other guy treats it as a preference list, we're all set. If the other guy treats it as a capability set, then we're no worse off then we'd be otherwise. David From jmoore3rd at bellsouth.net Tue May 19 01:14:08 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 18 May 2009 19:14:08 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A11E20D.8070109@sixdemonbag.org> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> <4A11E20D.8070109@sixdemonbag.org> Message-ID: <4A11EBC0.7060008@bellsouth.net> Robert J. Hansen wrote: > Not so much a conflict as a let's-not-be-hasty. According to the spec, > it must be an ordered preference list, but the other guy isn't required > to treat it as anything other than a capability set. As far as I can tell, I can run with: personal-digest-preferences H10 H9 H8 H11 I can set this on both My Key and in gpg.conf, BUT; if My correspondent can only or insists upon only using SHA1 or RIPEMD160 then My "preferences' will be ignored but I'd still like to be able to verify the hash. Rob correctly pointed out that inertia is a powerful force. Look at the amazing inroads that have been made in getting folks to even adopt encryption. :-\ Every time I read 'must' I shake My head and correct it to 'highly recommend/encourage' because as soon as the software is changed to 'force' Me to do something I'm gonna lay My ears back and rebel. Hardly a week passes by that I don't encounter someone 'offering' PGP 6.5.8ckt. The louder knowledgeable people scream that it is deprecated & dangerous the louder the 'unwashed' hear: It is 'forbidden' therefore it must be desirable for some reason. A Preference is exactly that; something I prefer. I can't, and shouldn't even try to, make You prefer it too. I can explain My reasoning and hope You'll adopt it but if changes I [or anyone] think are important/critical are suddenly introduced the majority will become very confused. To prevent the Hashing system from becoming the algorithm equivalent of the Tower of Babble then I feel the intelligent course of action is to allow Me My Preferences but don't rob Me of My Capabilities. While everyone is busy trying to eliminate SHA1 I'd like to also learn more about the last time a Hash was discontinued. H6 - TIGER192 once existed but was successfully retired. How long did this take? How was it accomplished? What, if any, repercussions followed? What if SHA1 were phased out while at the same time offering a replacement that was more attractive. Say, WHIRLPOOL. SHA1 has been around so long that it can't just be abandoned; this would feel like throwing the baby out with the bathwater. :-\ Just My musings after days of following this thread. Sorry for the interruption. :-D JOHN ;) Timestamp: Monday 18 May 2009, 19:13 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue May 19 01:24:17 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 19:24:17 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A119FB1.2060202@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> <4A119FB1.2060202@fifthhorseman.net> Message-ID: On May 18, 2009, at 1:49 PM, Daniel Kahn Gillmor wrote: > On 05/18/2009 01:21 PM, David Shaw wrote: >> Understood, but I believe the quote from me that was used was from >> that >> context, so I wanted to make that context clear. I don't really >> favor >> this sort of "here's how to transition everyone" document. > > I think that Robert started the document in an attempt to address your > earlier concern that there was a lot of bad advice floating around on > the 'net: > > http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025054.html > > Are you saying that you think such a document is a bad idea in > general, > and you'd never consider endorsing such a thing? "Never" is perhaps too strong, but in for this particular issue, yes, I do think it's a less than good idea. It puts forth a confusing message where GPG says one thing, but this additional document says something else. If I felt that these sorts of actions were necessary, I'd argue to change the defaults in GPG and not use a secondary document at all. > Is there a better way to address the legitimate concern you've raised? The documents I've seen thus far all seem to read (with varying levels of severity) "You're at risk. Do this to not be at risk any longer." I'd prefer a document that says "We think you're fine if you do nothing. If we thought you were at risk, we'd take action. We're happy to teach you about the issues so you can determine for yourself whether you agree with us or not." Which raises the question why a document is needed, since that's the normal case for GPG. I don't know how that concern can be addressed, really. I think there is fairly substantial disagreement on how severe the problem is, which is a fine thing as it makes people re-examine what they do believe, but it also makes it hard to come up with a document that would make everyone happy. >> Not all users of OpenPGP use the keyservers or even participate in >> the >> web of trust. It's also used in various environments where keys are >> traded manually. > > True. For those who do not participate in the WoT, the choice of > cert-digest-algo is irrelevant, though (they don't interpret > certificates at all), so we can ignore those people in this > consideration. That is unfortunately not true. Just because they don't make their keys part of the public web of trust doesn't mean they don't certify each other. David From dshaw at jabberwocky.com Tue May 19 01:29:06 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 19:29:06 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A11DEF9.3070509@sixdemonbag.org> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <4A11DEF9.3070509@sixdemonbag.org> Message-ID: <9C825223-12CD-4E69-8574-E2E73FD79901@jabberwocky.com> On May 18, 2009, at 6:19 PM, Robert J. Hansen wrote: >> * re-order them in a clearly-stated way (i.e. commit to saying "gpg >> interprets and produces the orderings as preferential, with most- >> desired >> first"), and explicitly, publically prefer digests from the SHA-2 >> family >> over SHA-1. > > This would require a modification to the current code, which I would > feel kind of bad about. I harped on the importance of considering the > recipient's preferences for quite a while; finally, David was kind > enough to change algorithm selection so that it works by a modified > Borda count. We'd have to revisit that code, but I don't see as how > it > would be too difficult. I'm not sure I follow where you're going with this. What code change would be necessary? GPG already interprets the preferences in ranked order. David From dkg at fifthhorseman.net Tue May 19 02:21:03 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 18 May 2009 20:21:03 -0400 Subject: SHA-1 recommendations In-Reply-To: References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <564A80FB-0D88-4CC6-972E-89C6C3DA2500@jabberwocky.com> <4A119FB1.2060202@fifthhorseman.net> Message-ID: <4A11FB6F.1060208@fifthhorseman.net> On 05/18/2009 07:24 PM, David Shaw wrote: > "Never" is perhaps too strong, but in for this particular issue, yes, I > do think it's a less than good idea. It puts forth a confusing message > where GPG says one thing, but this additional document says something > else. If I felt that these sorts of actions were necessary, I'd argue > to change the defaults in GPG and not use a secondary document at all. The advantage to creating these documents (particularly those targeted at more-sophisticated users, which i tried (but apparently failed) to do with my initial blog post) is that it can create a "pilot" pool of folks who can say "i've tried these settings for a while, and ran into these problems", which can then inform a default settings change. dkg wrote: >> True. For those who do not participate in the WoT, the choice of >> cert-digest-algo is irrelevant, though (they don't interpret >> certificates at all), so we can ignore those people in this >> consideration. > > That is unfortunately not true. Just because they don't make their keys > part of the public web of trust doesn't mean they don't certify each other. I addressed those people later in the original message (though i don't have good ideas for how to measure them). I didn't mean to conflate them with the group who uses the WoT but not the public keyservers. I consider the WoT to include the "dark" areas (i maintain several certificates like this), as well as the areas in the public keyservers. At any rate, i'm still interested in ideas about how we can know when a change in the default cert-digest-algo would be warranted. Suggestions? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue May 19 02:55:10 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 May 2009 20:55:10 -0400 Subject: SHA-1 recommendations In-Reply-To: <9C825223-12CD-4E69-8574-E2E73FD79901@jabberwocky.com> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <4A11DEF9.3070509@sixdemonbag.org> <9C825223-12CD-4E69-8574-E2E73FD79901@jabberwocky.com> Message-ID: <4A12036E.9030900@sixdemonbag.org> David Shaw wrote: > I'm not sure I follow where you're going with this. What code change > would be necessary? GPG already interprets the preferences in ranked > order. As I understood the proposal, even if a user put SHA-1 at the top of their preflist, we should consider it to be dropped to the bottom. That would necessitate some changing to the code. Of course, it's possible that I'm misunderstanding either or both of the proposal and the code. :) From dshaw at jabberwocky.com Tue May 19 03:49:02 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 18 May 2009 21:49:02 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A12036E.9030900@sixdemonbag.org> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <4A11DEF9.3070509@sixdemonbag.org> <9C825223-12CD-4E69-8574-E2E73FD79901@jabberwocky.com> <4A12036E.9030900@sixdemonbag.org> Message-ID: On May 18, 2009, at 8:55 PM, Robert J. Hansen wrote: > David Shaw wrote: >> I'm not sure I follow where you're going with this. What code change >> would be necessary? GPG already interprets the preferences in ranked >> order. > > As I understood the proposal, even if a user put SHA-1 at the top of > their preflist, we should consider it to be dropped to the bottom. > That > would necessitate some changing to the code. Of course, it's possible > that I'm misunderstanding either or both of the proposal and the > code. :) Ah. I thought Daniel was proposing that we just change the default hash preferences on new keys to something that puts SHA-2 before SHA-1. Possibly I missed a message somewhere. I didn't see the other proposal. It's not particularly difficult to do this, and we already do something similar for MD5. If the algorithm selection happens to settle on MD5, we silently swap in SHA-1 instead. If the user explicitly chooses MD5 (either via digest-algo or by putting it in their personal-digest-prefs), then the conclusion is that they really meant to pick MD5 and so MD5 is used. I don't think we're at the point of wanting to do this for SHA-1, though. David From dkg at fifthhorseman.net Tue May 19 06:59:29 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 May 2009 00:59:29 -0400 Subject: SHA-1 recommendations In-Reply-To: References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <4A11DEF9.3070509@sixdemonbag.org> <9C825223-12CD-4E69-8574-E2E73FD79901@jabberwocky.com> <4A12036E.9030900@sixdemonbag.org> Message-ID: <4A123CB1.8030106@fifthhorseman.net> On 05/18/2009 09:49 PM, David Shaw wrote: > On May 18, 2009, at 8:55 PM, Robert J. Hansen wrote: >> As I understood the proposal, even if a user put SHA-1 at the top of >> their preflist, we should consider it to be dropped to the bottom. That >> would necessitate some changing to the code. Of course, it's possible >> that I'm misunderstanding either or both of the proposal and the >> code. :) > > Ah. I thought Daniel was proposing that we just change the default hash > preferences on new keys to something that puts SHA-2 before SHA-1. > Possibly I missed a message somewhere. I didn't see the other proposal. All i had proposed in this particular point was changing the value of default-preference-list to: SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 I'm *not* proposing any other changes to default-preference-list. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue May 19 10:42:04 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 May 2009 10:42:04 +0200 Subject: Make --enable-dsa2 the default? In-Reply-To: (David Shaw's message of "Mon, 18 May 2009 09:24:25 -0400") References: <87vdo0szj4.fsf@wheatstone.g10code.de> <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> <87ws8f6lfx.fsf@wheatstone.g10code.de> Message-ID: <87ljot32n7.fsf@wheatstone.g10code.de> On Mon, 18 May 2009 15:24, dshaw at jabberwocky.com said: > I wonder if the ideal change would be to remove the --enable-dsa2 > block on new keys, but leave it in place in general. That would mean You mean, in ask_keysize: switch(algo) { case PUBKEY_ALGO_DSA: if(opt.flags.dsa2) { def=2048; max=3072; } else { tty_printf(_("DSA keypair will have %u bits.\n"),1024); return 1024; } break; we simply remove the test and allow selection of the size? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue May 19 12:11:58 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 May 2009 12:11:58 +0200 Subject: SHA-1 recommendations In-Reply-To: <4A108551.1070207@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 17 May 2009 17:44:49 -0400") References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> Message-ID: <87hbzh2yhd.fsf@wheatstone.g10code.de> On Sun, 17 May 2009 23:44, dkg at fifthhorseman.net said: > cannot handle more stronger digest algorithms. For example RFC 4055 > (from June 2005) appears to list SHA-2 algorithms for X.509: Well, this is an RFC but not the real world. You should consider RFCs in the X.509 world as an attempt to document what some systems in some special version may try to implement at some time. The German signature law for example requires the use of SHA-256 since this year. However there are a lot of problems, for example the need to implement the gpgsm option --extra-digest-algo to allow verification with gpgsm because some software used by the folks creating signatures mixes SHA-1 and SHA-256 in an incompatible way. I wish that X.509 would go away, too. However, no hunger and peace are an easier goal than getting rid of X.509. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Tue May 19 16:56:11 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 May 2009 10:56:11 -0400 Subject: Make --enable-dsa2 the default? In-Reply-To: <87ljot32n7.fsf@wheatstone.g10code.de> References: <87vdo0szj4.fsf@wheatstone.g10code.de> <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> <87ws8f6lfx.fsf@wheatstone.g10code.de> <87ljot32n7.fsf@wheatstone.g10code.de> Message-ID: On May 19, 2009, at 4:42 AM, Werner Koch wrote: > On Mon, 18 May 2009 15:24, dshaw at jabberwocky.com said: > >> I wonder if the ideal change would be to remove the --enable-dsa2 >> block on new keys, but leave it in place in general. That would mean > > You mean, in ask_keysize: > > switch(algo) > { > case PUBKEY_ALGO_DSA: > if(opt.flags.dsa2) > { > def=2048; > max=3072; > } > else > { > tty_printf(_("DSA keypair will have %u bits.\n"),1024); > return 1024; > } > break; > > we simply remove the test and allow selection of the size? Yes. There are really two different things that --enable-dsa2 actually enables. First, it means that we can have a DSA key that is bigger than 1024 bits. The other is that we can use hashes larger than the q size by truncating them. If we make the ask_keysize change, we're always enabling the first one. The code is smart enough to automatically enable the second one whenever it sees a key with q! =160, so DSA2 keys will always work properly. It basically means we would redefine --enable-dsa2 to be "Allow hash truncation for existing DSA keys". David From dkg at fifthhorseman.net Tue May 19 18:52:54 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 19 May 2009 12:52:54 -0400 Subject: SHA-1 recommendations In-Reply-To: <4A123CB1.8030106@fifthhorseman.net> References: <4A0E366E.7030601@sixdemonbag.org> <4A108551.1070207@fifthhorseman.net> <4A108F53.7000601@sixdemonbag.org> <4A10AD77.8090904@fifthhorseman.net> <34398DE3-F060-4F0B-9B15-44BA409E6331@jabberwocky.com> <4A117B49.5090200@fifthhorseman.net> <4A11DEF9.3070509@sixdemonbag.org> <9C825223-12CD-4E69-8574-E2E73FD79901@jabberwocky.com> <4A12036E.9030900@sixdemonbag.org> <4A123CB1.8030106@fifthhorseman.net> Message-ID: <4A12E3E6.2060109@fifthhorseman.net> On 05/19/2009 12:59 AM, Daniel Kahn Gillmor wrote: > All i had proposed in this particular point was changing the value of > default-preference-list to: > > SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 I've filed this, and included (and tested) a patch: https://bugs.g10code.com/gnupg/issue1057 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue May 19 19:01:21 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 May 2009 19:01:21 +0200 Subject: Make --enable-dsa2 the default? In-Reply-To: (David Shaw's message of "Tue, 19 May 2009 10:56:11 -0400") References: <87vdo0szj4.fsf@wheatstone.g10code.de> <4E484253-B251-4684-9C8D-E435E1B46A22@jabberwocky.com> <87ws8f6lfx.fsf@wheatstone.g10code.de> <87ljot32n7.fsf@wheatstone.g10code.de> Message-ID: <87d4a52fj2.fsf@wheatstone.g10code.de> On Tue, 19 May 2009 16:56, dshaw at jabberwocky.com said: > It basically means we would redefine --enable-dsa2 to be "Allow hash > truncation for existing DSA keys". Okay, I'll do it this way. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From subs at christiantena.net Mon May 18 22:42:50 2009 From: subs at christiantena.net (Philip) Date: Mon, 18 May 2009 21:42:50 +0100 Subject: gpgme and delphi/pascal ? Message-ID: <4A11C84A.5050700@christiantena.net> Hi I hope that this is the right place to ask. Apologies if not. These days I'm becoming a half decent amateur Lazarus/Freepascal programmer, but I've not been able to read/write pgp encrypted files in a pascal program. The way to go according to the documentation seems to be to use gpgme, which is fine if you are a C programmer, but I'm not and probably never will be. The only thing I can find is this http://www.gnu-pascal.de/contrib/nicola/gpgme.pas which seems to be a pascal unit which wraps up static linking of gpgme C libraries, but it's not something I've done before, and I can't figure it out. Is there anyone here who has done before what I'm trying to achieve? thanks, Philip From hira at atlas-is.co.jp Wed May 20 09:06:57 2009 From: hira at atlas-is.co.jp (HIRA, Shuichi) Date: Wed, 20 May 2009 16:06:57 +0900 Subject: gpgme and delphi/pascal ? In-Reply-To: <4A11C84A.5050700@christiantena.net> References: <4A11C84A.5050700@christiantena.net> Message-ID: <200905200706.AA02859@VELA.sun.atlas-is.co.jp> Hi, >Is there anyone here who has done before what I'm trying to achieve? I did like below. 1: Make dll from gpgme, using Borland C++ Compiler 5.5 (needs some modify) 2: Call it from Delphi I made a dll call unit like Windows.pas style, and wrapper classes. These sources are closed, sorry. -- HIRA, Shuichi Atlas Information Service Inc. IT Development and Promotion Dept. hira at atlas-is.co.jp From wk at gnupg.org Wed May 20 13:16:26 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 May 2009 13:16:26 +0200 Subject: gpgme and delphi/pascal ? In-Reply-To: <200905200706.AA02859@VELA.sun.atlas-is.co.jp> (Shuichi HIRA's message of "Wed, 20 May 2009 16:06:57 +0900") References: <4A11C84A.5050700@christiantena.net> <200905200706.AA02859@VELA.sun.atlas-is.co.jp> Message-ID: <87bppo10tx.fsf@wheatstone.g10code.de> On Wed, 20 May 2009 09:06, hira at atlas-is.co.jp said: > 1: Make dll from gpgme, using Borland C++ Compiler 5.5 (needs some modify) Please don't do that. We already have a DLL with a well defined ABI and you should use that. If you want the binary, install gpg4win. If you need to build it yourself, the regular gpgme source tarball is prepared for a cross build (just do: "./autogen.sh --build-w32"). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From subs at christiantena.net Wed May 20 17:46:10 2009 From: subs at christiantena.net (Philip) Date: Wed, 20 May 2009 16:46:10 +0100 Subject: gpgme and delphi/pascal ? In-Reply-To: <87bppo10tx.fsf@wheatstone.g10code.de> References: <4A11C84A.5050700@christiantena.net> <200905200706.AA02859@VELA.sun.atlas-is.co.jp> <87bppo10tx.fsf@wheatstone.g10code.de> Message-ID: <4A1425C2.2040401@christiantena.net> Werner Koch wrote: > On Wed, 20 May 2009 09:06, hira at atlas-is.co.jp said: > >> 1: Make dll from gpgme, using Borland C++ Compiler 5.5 (needs some modify) > > Please don't do that. We already have a DLL with a well defined ABI and > you should use that. If you want the binary, install gpg4win. If you > need to build it yourself, the regular gpgme source tarball is prepared > for a cross build (just do: "./autogen.sh --build-w32"). > > > Shalom-Salam, > > Werner > Thanks, I already have gpg4win installed so I will look at that. Given that lazarus/freepascal can compile the same source for Linux and Windows, is there an easy way to do it in a portable way? regards, Philip From lists at lina.inka.de Thu May 21 02:11:56 2009 From: lists at lina.inka.de (Bernd Eckenfels) Date: Thu, 21 May 2009 02:11:56 +0200 Subject: gpgme and delphi/pascal ? In-Reply-To: <4A1425C2.2040401@christiantena.net> References: <4A11C84A.5050700@christiantena.net> <200905200706.AA02859@VELA.sun.atlas-is.co.jp> <87bppo10tx.fsf@wheatstone.g10code.de> <4A1425C2.2040401@christiantena.net> Message-ID: <20090521001156.GA19357@lina.inka.de> On Wed, May 20, 2009 at 04:46:10PM +0100, Philip wrote: > I already have gpg4win installed so I will look at that. > Given that lazarus/freepascal can compile the same source for Linux and > Windows, is there an easy way to do it in a portable way? I know it is frowned upon and I will get blamed for suggesting this, but just for the gpg executable from pascal. This requires some work, but I guess its still less work than getting the link symbols and data structures match. Gruss Bernd -- (OO) -- Bernd_Eckenfels at M?rscher_Strasse_8.76185Karlsruhe.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E eckes at IRCNet v:+497211603874 f:+49721151516129 (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From hira at atlas-is.co.jp Thu May 21 03:17:37 2009 From: hira at atlas-is.co.jp (HIRA, Shuichi) Date: Thu, 21 May 2009 10:17:37 +0900 Subject: gpgme and delphi/pascal ? In-Reply-To: <87bppo10tx.fsf@wheatstone.g10code.de> References: <87bppo10tx.fsf@wheatstone.g10code.de> Message-ID: <200905210117.AA02861@VELA.sun.atlas-is.co.jp> Hi, >> 1: Make dll from gpgme, using Borland C++ Compiler 5.5 (needs some modify) >Please don't do that. We already have a DLL with a well defined ABI and >you should use that. If you want the binary, install gpg4win. If you I didn't know gpg4win has that dll. I did it at 2006, I didn't know gpg4win itself. I saw Sylpheed and its old version uses own built dll. Perhaps, I did same way. (Latest Sylpheed uses libgpgme-11.dll) I will rewrite my class for libgpgme-11.dll later. If I can open it, should I do? Thx. -- HIRA, Shuichi Atlas Information Service Inc. IT Development and Promotion Dept. hira at atlas-is.co.jp From nicholas.cole at gmail.com Thu May 21 12:32:14 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 21 May 2009 11:32:14 +0100 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <8763g34x25.fsf@pond.riseup.net> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> Message-ID: On Thu, May 14, 2009 at 2:46 PM, Micah Anderson wrote: > David Shaw writes: > >> I don't mean there are faster/easier/cheaper ways of doing this >> mathematically. ?I mean boring old subterfuge like going to a >> keysigning party with a fake ID, claiming to be someone else. ?I get a >> bunch of signatures, and I'm done. ?It skips the whole difficult math >> problem. >> >> I'm all for strong crypto protection against impersonation, but when >> there is a non-crypto impersonation attack that has essentially the >> same end result as a crypto impersonation attack, and the non-crypto >> variant of the attack is vastly cheaper, faster, and easier than the >> crypto attack, I do start to wonder what the point is of putting a >> strong crypto defense against the crypto attack. I've never quite understood "Key Signing Parties" for this reason. It seems to me that OpenPGP and its web of trust provide an excellent way to represent technically and securely trust relationships that already exist. You can't use OpenPGP to create trust that doesn't exist outside the system. Best, NC From rjh at sixdemonbag.org Thu May 21 15:09:29 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 May 2009 09:09:29 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> Message-ID: <4A155289.4070602@sixdemonbag.org> Nicholas Cole wrote: > I've never quite understood "Key Signing Parties" for this reason. The reason is at least half social. It's a good excuse to get out of the house and meet other people who have a shared interest. For the most part, people at keysigning parties do not follow very good document protocol -- if someone presented me with, say, an Arkansas driver's license, I've never seen an Arkansas driver's license before, so how could I know what one looks like or what security features to look for? Passports are far better and easier to check -- if I want to know what to look for to make sure a passport is real, I just visit the website of the issuing government. From dshaw at jabberwocky.com Thu May 21 16:27:41 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 21 May 2009 10:27:41 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> Message-ID: <86C1AD1A-0D0C-489A-A67F-43791CF9CB10@jabberwocky.com> On May 21, 2009, at 6:32 AM, Nicholas Cole wrote: > On Thu, May 14, 2009 at 2:46 PM, Micah Anderson > wrote: >> David Shaw writes: >> >>> I don't mean there are faster/easier/cheaper ways of doing this >>> mathematically. I mean boring old subterfuge like going to a >>> keysigning party with a fake ID, claiming to be someone else. I >>> get a >>> bunch of signatures, and I'm done. It skips the whole difficult >>> math >>> problem. >>> >>> I'm all for strong crypto protection against impersonation, but when >>> there is a non-crypto impersonation attack that has essentially the >>> same end result as a crypto impersonation attack, and the non-crypto >>> variant of the attack is vastly cheaper, faster, and easier than the >>> crypto attack, I do start to wonder what the point is of putting a >>> strong crypto defense against the crypto attack. > > I've never quite understood "Key Signing Parties" for this reason. It > seems to me that OpenPGP and its web of trust provide an excellent way > to represent technically and securely trust relationships that already > exist. You can't use OpenPGP to create trust that doesn't exist > outside the system. Key signing parties can't really create trust relationships, but they're not intended to. Key signing parties are for proving identity. Opinions may vary whether they do that well enough, but the intent is just to make a strong binding between a human being and a key. Whether people then choose to trust signatures from that key is up to them. Mind you, I don't think that people at key signing parties verify identity particularly well either, but at least identity is a more tractable problem than trust. There is a built-in assumption in the classic web of trust that some identity verifiers are better than others. See the "full" and "marginal" ownertrust settings, for example, and there are tunable options as to how many "full" signatures or "marginal" signatures are needed to establish identity for the user. David From nd at syndicat.com Thu May 21 15:48:36 2009 From: nd at syndicat.com (Niels Dettenbach) Date: Thu, 21 May 2009 15:48:36 +0200 Subject: AW: Re: laying groundwork for an eventual migration away from SHA1 with gpg Message-ID: Hmmm, Keysigning parties makes sense if they strictly follow serious procedures and requirements - but can't give a 100% security (as the most other identity checks too). Even a Passport could be modified or cheated. In most european countries it should be relative easy to make the Passport or Personal ID a requirement for each party member because at least one of both is a must by law and these documents are standardized during most european countries, known by everyone and made on a relative high security level mainly. On a european level the european drivers license could work too. But - in each case - you have to prove the document by a list of security features which are publically documented by the government. I remember such practises by the european border passport control where the controllers used a okular like a small microscope to check the (even the newer biometric) passports of all travellers from iraq. It seems they didn't fully trust their own biometrical ID system byself. It seems it is not easy to prove a public document without good (or may be special) knowledge about the documents. On the other hand you get officially identified on any postal office i.e. in germany (i.e. to open a bank account) where no one seems to check the documents so hard like here. >From my experience there are very different levels of key-signing parties. The web of trust is not reflecting this levels in most cases. Cheers, Niels. --- Niels Dettenbach Syndicat IT&Internet http://www.syndicat.com From rjh at sixdemonbag.org Thu May 21 16:59:21 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 May 2009 10:59:21 -0400 Subject: AW: Re: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: References: Message-ID: <4A156C49.2040909@sixdemonbag.org> This subject is increasingly off-topic for -devel. I've cc'd this message to -users; let's see if we can't move the thread there. Niels Dettenbach wrote: > Hmmm, Keysigning parties makes sense if they strictly follow serious > procedures and requirements - but can't give a 100% security (as the > most other identity checks too). Even a Passport could be modified or > cheated. With a high-quality forged passport I can not only travel -- I can also vote, run for (most) public offices, get utilities in my name, open bank accounts, and so on. Those secondary pieces of documentation won't be forgeries, they'll be real -- and once I have them, I destroy my forged passport and settle into my new assumed identity. If the attacker is smart enough and savvy enough to get a high-quality forged passport, there's no way they'll present it for inspection to someone who's actively looking for a forged passport. They'll present their real (obtained illegally and containing incorrect information, but quite real) identity documents instead. Further, you won't find 100% security anywhere. Pursuing it is an ephemera. You won't get there, and if you obsess over it your obsession will ultimately hurt your security. From jmoore3rd at bellsouth.net Thu May 21 20:12:06 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 21 May 2009 14:12:06 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A155289.4070602@sixdemonbag.org> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> <4A155289.4070602@sixdemonbag.org> Message-ID: <4A159976.1000708@bellsouth.net> Robert J. Hansen wrote: > Passports are far better and easier to check -- if I want to know what > to look for to make sure a passport is real, I just visit the website of > the issuing government. Presumably this tactic would also be effective by visiting a State Website. Alas, the majority of Key signing Parties result mostly in "I was there and spoke with...." Signatures. It's hard to imagine how shaking more hands than a politician on Runoff Day can convey any sense of 'trustworthiness' about the other individual. :-\ Still, BoF Parties can be a helluva lot of fun. :) JOHN ;) Timestamp: Thursday 21 May 2009, 14:11 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu May 21 20:23:04 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 May 2009 14:23:04 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A159976.1000708@bellsouth.net> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> <4A155289.4070602@sixdemonbag.org> <4A159976.1000708@bellsouth.net> Message-ID: <4A159C08.4060704@fifthhorseman.net> On 05/21/2009 02:12 PM, John W. Moore III wrote: > It's hard to imagine how > shaking more hands than a politician on Runoff Day can convey any sense > of 'trustworthiness' about the other individual. :-\ As David pointed out, keysignings are about establishing identity, *not* establishing trust or any measure of trustworthiness. Standard OpenPGP certifications (the output generated by a keysigning party) say nothing about trustworthiness either, they simply make a claim about identity. It is when you *evaluate* such certifications that you must make decisions about the trustworthiness of each certifier. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu May 21 20:24:53 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 21 May 2009 14:24:53 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A159976.1000708@bellsouth.net> References: <4A01226D.4050606@fifthhorseman.net> <97618F71-F4DD-4F10-B242-6C33A4D8AE72@jabberwocky.com> <4A034B33.8050901@fifthhorseman.net> <8A8B2763-4FB3-4B22-BD86-CFB2FC430C73@jabberwocky.com> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> <4A155289.4070602@sixdemonbag.org> <4A159976.1000708@bellsouth.net> Message-ID: <4A159C75.9030203@sixdemonbag.org> (also cc'd to GnuPG-Users. This thread seems like it's more appropriate there; let's continue it there if possible.) John W. Moore III wrote: > Presumably this tactic would also be effective by visiting a State > Website. I chose the example I did because I couldn't find information on Arkansas driver's license security features in a five minute web search. Other states may be different, I don't know. > Still, BoF Parties can be a helluva lot of fun. :) Yeah, that's why I show up to the keysigning BoFs at conventions. :) From wk at gnupg.org Fri May 22 12:12:49 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 May 2009 12:12:49 +0200 Subject: gpgme and delphi/pascal ? In-Reply-To: <200905210117.AA02861@VELA.sun.atlas-is.co.jp> (Shuichi HIRA's message of "Thu, 21 May 2009 10:17:37 +0900") References: <87bppo10tx.fsf@wheatstone.g10code.de> <200905210117.AA02861@VELA.sun.atlas-is.co.jp> Message-ID: <87vdntxx7i.fsf@wheatstone.g10code.de> On Thu, 21 May 2009 03:17, hira at atlas-is.co.jp said: > I will rewrite my class for libgpgme-11.dll later. > If I can open it, should I do? We won't change the API in an incompatible way including the assigned ordinals (see src/gpgme.def). We use the MS ABI, the only gotcha is to use a plain free() for allocated memmory returned by GPGME; you must use gpgme_free. This is required to cope with different MS C runtime versions. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From john.marshall at riverwillow.com.au Sat May 23 07:47:09 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Sat, 23 May 2009 15:47:09 +1000 Subject: gpg 2.0.11 reports invalid packets on keys from gpg 1.4.9 and keyservers Message-ID: <20090523054709.GA27231@rwpc12.mby.riverwillow.net.au> I was originally looking at this as a keyserver problem but it has been pointed out to me that this problem cannot be reproduced with GnuPG 1.4.9. - Using GnuPG 1.4.9, I can download key 0xFC05DA69 from any keyserver I've tried with no problem at all. - Using GnuPG 2.0.11, the only keyservers from which I have been able to download the key are SKS 1.0.10 keyservers. - If I download the key using GnuPG 1.4.9 and then use GnuPG 1.4.9 to export the key to a file, I can import that key with GnuPG 1.4.9 but not with GnuPG 2.0.11. Also GnuPG 2.0.11 cannot read the key from the keyring to which GnuPG 1.4.9 imported it. I have concluded that GnuPG 2.0.11 does not like the way that this key is stored or exported by: - PKS 0.6.9 - SKS 1.1.0 - GnuPG 1.4.9 but GnuPG 1.4.9 works happily with all of these. I think this probably means that those three implementations are all broken, or that GnuPG 2.0.11 is not handling some corner case properly. If I add --debug-all to the gpg imports, this is what I see: Using GnuPG 2.0.11 (breaks): 347 gpg: DBG: parse_packet(iob=1): type=2 length=540 (parse.import.c.376) 348 gpg: DBG: parse_packet(iob=1): type=2 length=540 (parse.import.c.376) 349 gpg: DBG: parse_packet(iob=1): type=13 length=42 (parse.import.c.376) 350 gpg: DBG: parse_packet(iob=1): type=2 length=30 (parse.import.c.376) 351 gpg: read_block: read error: Invalid packet Using GnuPG 1.4.9 (works): 1542 gpg: DBG: parse_packet(iob=2): type=2 length=540 (parse.import.c.372) 1543 gpg: DBG: mpi_alloc(4096) 1544 gpg: DBG: mpi_alloc_limb_space(4096) 1545 gpg: DBG: parse_packet(iob=2): type=2 length=540 (parse.import.c.372) 1546 gpg: DBG: mpi_alloc(4096) 1547 gpg: DBG: mpi_alloc_limb_space(4096) 1548 gpg: DBG: parse_packet(iob=2): type=13 length=42 (parse.import.c.372) 1549 gpg: DBG: parse_packet(iob=2): type=2 length=30 (parse.import.c.372) 1550 gpg: DBG: mpi_alloc(0) 1551 gpg: DBG: mpi_alloc(0) Data Point: Depending on the source, Key 0xFC05DA69 had more or less signatures: - 547 signatures (from SKS 1.0.10) - 548 signatures (from PKS 0.6.9) - 549 signatures (from SKS 1.1.0) Perhaps SKS 1.0.10 silently ignores "problem" bits of the key? GnuPG 2.0.11 was perfectly happy with the 547-signature edition of the key. Please note that in an endeavour to eliminate discussion about keyservers and armor, I believe I have reduced this to a pure GnuPG native export/import issue across versions. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From nicholas.cole at gmail.com Sat May 23 21:51:27 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 23 May 2009 20:51:27 +0100 Subject: RSA+RSA is now the default In-Reply-To: <87zldcszvb.fsf@wheatstone.g10code.de> References: <87zldcszvb.fsf@wheatstone.g10code.de> Message-ID: On Sun, May 17, 2009 at 1:00 PM, Werner Koch wrote: > Hi! > > I just committed changes to the GnuPG trunk to make RSA with an RSA > subkey the default. ?This also changes the order of the presented > algorithms, but 1 is still the default. Dear Warner, Will the order of the add sub key menu of algorithms also change? Consistency across versions is always a good thing. IIRC in the past when algorithms have changed or been removed the menus have remained as consistent as possible across versions. So, for example, there is no particular reason why the default answer has to be number 1. Best wishes, Nicholas From fred.kantor at gmail.com Sun May 24 13:49:41 2009 From: fred.kantor at gmail.com (Fred Kantor) Date: Sun, 24 May 2009 07:49:41 -0400 Subject: laying groundwork for an eventual migration away from SHA1 with gpg In-Reply-To: <4A159C75.9030203@sixdemonbag.org> References: <4A01226D.4050606@fifthhorseman.net> <4A045E0C.6000304@fifthhorseman.net> <946F33F5-5F87-4BF7-A581-4B81B6856332@jabberwocky.com> <4A049D52.3000304@fifthhorseman.net> <0945226C-197C-4ED6-9A27-E9272A6FEA3F@jabberwocky.com> <8763g34x25.fsf@pond.riseup.net> <4A155289.4070602@sixdemonbag.org> <4A159976.1000708@bellsouth.net> <4A159C75.9030203@sixdemonbag.org> Message-ID: <6899a0d30905240449l53dfeda6ge4683f0da26430ca@mail.gmail.com> re identity -- may I suggest considering (a) DNA swipe(s) at key-signing party? On Thu, May 21, 2009 at 2:24 PM, Robert J. Hansen wrote: > (also cc'd to GnuPG-Users. ?This thread seems like it's more appropriate > there; let's continue it there if possible.) > > John W. Moore III wrote: >> Presumably this tactic would also be effective by visiting a State >> Website. > > I chose the example I did because I couldn't find information on > Arkansas driver's license security features in a five minute web search. > ?Other states may be different, I don't know. > >> Still, BoF Parties can be a helluva lot of fun. ?:) > > Yeah, that's why I show up to the keysigning BoFs at conventions. ?:) > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From wk at gnupg.org Mon May 25 10:04:58 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 May 2009 10:04:58 +0200 Subject: RSA+RSA is now the default In-Reply-To: (Nicholas Cole's message of "Sat, 23 May 2009 20:51:27 +0100") References: <87zldcszvb.fsf@wheatstone.g10code.de> Message-ID: <87ab51y5ed.fsf@wheatstone.g10code.de> On Sat, 23 May 2009 21:51, nicholas.cole at gmail.com said: > Will the order of the add sub key menu of algorithms also change? Yes, I changed them so that they are imho grouped in a more logically way. > So, for example, there is no particular reason why the default answer > has to be number 1. I thought about this and came to the conclusion that it is better to use 1 for the default. Despite that scripts should not use the menu to generate a key, I am pretty sure that there are some applications which do it nevertheless. Using 1 for the default ensures that the new default is taken. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon May 25 10:42:36 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 May 2009 10:42:36 +0200 Subject: gpg 2.0.11 reports invalid packets on keys from gpg 1.4.9 and keyservers In-Reply-To: <20090523054709.GA27231@rwpc12.mby.riverwillow.net.au> (John Marshall's message of "Sat, 23 May 2009 15:47:09 +1000") References: <20090523054709.GA27231@rwpc12.mby.riverwillow.net.au> Message-ID: <873aaty3nn.fsf@wheatstone.g10code.de> On Sat, 23 May 2009 07:47, john.marshall at riverwillow.com.au said: > Please note that in an endeavour to eliminate discussion about > keyservers and armor, I believe I have reduced this to a pure GnuPG > native export/import issue across versions. Can you please send me that key by PM? I just build a vanilla 2.0.11 and imported my copy of the key without problems: $ GNUPGHOME=`pwd` sh sh-2.05b$ ./gpg2 -k gpg: WARNING: unsafe permissions on homedir `/foo/gnupg-2.0.11/g10' gpg: keyring `/foo/gnupg-2.0.11/g10/pubring.gpg' created gpg: /foo/gnupg-2.0.11/g10/trustdb.gpg: trustdb created sh-2.05b$ ./gpg2 -v --import ~/anand.gpg gpg: WARNING: unsafe permissions on homedir `/foo/gnupg-2.0.11/g10' gpg: keyring `/foo/gnupg-2.0.11/g10/secring.gpg' created gpg: pub 1024R/FC05DA69 1997-05-12 Anand xxxxxx gpg: using PGP trust model gpg: key FC05DA69: public key "Anand xxxxx" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: 1 keys cached (547 signatures) gpg: 0 keys processed (0 validity counts cleared) gpg: no ultimately trusted keys found Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From nicholas.cole at gmail.com Mon May 25 18:51:23 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 May 2009 17:51:23 +0100 Subject: RSA+RSA is now the default In-Reply-To: References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> Message-ID: On Mon, May 25, 2009 at 5:46 PM, Nicholas Cole wrote: > On Mon, May 25, 2009 at 9:04 AM, Werner Koch wrote: >> On Sat, 23 May 2009 21:51, nicholas.cole at gmail.com said: >> >>> Will the order of the add sub key menu of algorithms also change? >> >> Yes, I changed them so that they are imho grouped in a more logically >> way. > > Could I therefore make a plea that the new order is clearly documented > in the Changelog? :-) PS. I don't suppose that an option like --use-consistent-menus (so that changes of this type did not upset frontends) would find any support? ;-) N From nicholas.cole at gmail.com Mon May 25 18:46:11 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 25 May 2009 17:46:11 +0100 Subject: RSA+RSA is now the default In-Reply-To: <87ab51y5ed.fsf@wheatstone.g10code.de> References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> Message-ID: On Mon, May 25, 2009 at 9:04 AM, Werner Koch wrote: > On Sat, 23 May 2009 21:51, nicholas.cole at gmail.com said: > >> Will the order of the add sub key menu of algorithms also change? > > Yes, I changed them so that they are imho grouped in a more logically > way. Could I therefore make a plea that the new order is clearly documented in the Changelog? :-) >> So, for example, there is no particular reason why the default answer >> has to be number 1. > > I thought about this and came to the conclusion that it is better to use > 1 for the default. ?Despite that scripts should not use the menu to > generate a key, I am pretty sure that there are some applications which > do it nevertheless. ?Using 1 for the default ensures that the new > default is taken. It's a small point and I don't mean to get side-tracked, but if any front-ends have used this menu, I rather fear that you have replaced one evil (not using the right default) with a worse one - presenting one thing in the front end and doing another behind the scenes! Best wishes, Nicholas From wk at gnupg.org Mon May 25 20:39:29 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 May 2009 20:39:29 +0200 Subject: RSA+RSA is now the default In-Reply-To: (Nicholas Cole's message of "Mon, 25 May 2009 17:51:23 +0100") References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> Message-ID: <87ws85t4bi.fsf@wheatstone.g10code.de> On Mon, 25 May 2009 18:51, nicholas.cole at gmail.com said: > PS. I don't suppose that an option like --use-consistent-menus (so > that changes of this type did not upset frontends) would find any > support? ;-) No. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon May 25 20:46:10 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 May 2009 20:46:10 +0200 Subject: RSA+RSA is now the default In-Reply-To: (Nicholas Cole's message of "Mon, 25 May 2009 17:46:11 +0100") References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> Message-ID: <87skitt40d.fsf@wheatstone.g10code.de> On Mon, 25 May 2009 18:46, nicholas.cole at gmail.com said: > Could I therefore make a plea that the new order is clearly documented > in the Changelog? :-) You mean so that it won't change in the future? I don't think that is a good idea. I expect users to actually read the menu. If they don't read it, I assume that they will select the first item and thus this should be the default. > It's a small point and I don't mean to get side-tracked, but if any > front-ends have used this menu, I rather fear that you have replaced That is quite possible. Making --fixed-list-mode the default was a more incompatible change; despite that I know only of one tool which fails (kgpg). Thus I doubt that there will be many problems with a change in this menu. Actually the key generation menu has always been dynamic (check --expert, --enable-dsa) and problems should have popped up already. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From cwal989 at comcast.net Tue May 26 06:16:58 2009 From: cwal989 at comcast.net (Christopher J. Walters) Date: Tue, 26 May 2009 00:16:58 -0400 Subject: RSA+RSA is now the default In-Reply-To: <87zldcszvb.fsf@wheatstone.g10code.de> References: <87zldcszvb.fsf@wheatstone.g10code.de> Message-ID: <4A1B6D3A.8030204@comcast.net> Werner Koch wrote: > Hi! > > I just committed changes to the GnuPG trunk to make RSA with an RSA > subkey the default. This also changes the order of the presented > algorithms, but 1 is still the default. The interactive --gen-key > has never been intended for use by frontends, thus this change may > only reveal buggy frontends ;-). Frontends should use the --batch > key generation with a parameter file and thus need to change the > default algorithm on their own (I already did this for GPA). [snip] > I hope this is okay. > > > Shalom-Salam, > > Werner Hi, That's no problem for me. I've been making RSA + RSA keypairs for some time now. Of course, I am the guy who tested out ECC... LOL! No one could read my messages - now that's secure. Regards, Chris From wk at gnupg.org Tue May 26 10:29:21 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 May 2009 10:29:21 +0200 Subject: [solved] Re: gpg 2.0.11 reports invalid packets on keys from gpg 1.4.9 and keyservers In-Reply-To: <20090523054709.GA27231@rwpc12.mby.riverwillow.net.au> (John Marshall's message of "Sat, 23 May 2009 15:47:09 +1000") References: <20090523054709.GA27231@rwpc12.mby.riverwillow.net.au> Message-ID: <87octgtggu.fsf@wheatstone.g10code.de> Hi! An older libgcrypt actually showed the problem: an mpi of size 0 is not allowed an mpi of size 0 is not allowed gpg: read_block: read error: Invalid packet thus finding the bug was easy after John sent me the full bad key. The bug is due to an inconsistency between Libgcrypt and and GnuPG-1.4. That problem must have been there for many years and will be fixed in Libgcrypt 1.5.0. For the time being I implemented a workaround in GnuPG. It is already commited SVN to trunk; find a patch below. Shalom-Salam, Werner --- g10/parse-packet.c (revision 5015) +++ g10/parse-packet.c (working copy) @@ -139,9 +139,19 @@ p[i+2] = iobuf_get(inp) & 0xff; nread++; } - if ( gcry_mpi_scan( &a, GCRYMPI_FMT_PGP, buf, nread, &nread ) ) - a = NULL; - + + if (nread >= 2 && !(buf[0] << 8 | buf[1])) + { + /* Libgcrypt < 1.5.0 accidently rejects zero-length (i.e. zero) + MPIs. We fix this here. */ + a = gcry_mpi_new (0); + } + else + { + if ( gcry_mpi_scan( &a, GCRYMPI_FMT_PGP, buf, nread, &nread ) ) + a = NULL; + } + leave: gcry_free(buf); if ( nread > *ret_nread ) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From john.marshall at riverwillow.com.au Tue May 26 11:49:23 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Tue, 26 May 2009 19:49:23 +1000 Subject: [solved] Re: gpg 2.0.11 reports invalid packets on keys from gpg 1.4.9 and keyservers In-Reply-To: <87octgtggu.fsf@wheatstone.g10code.de> References: <20090523054709.GA27231@rwpc12.mby.riverwillow.net.au> <87octgtggu.fsf@wheatstone.g10code.de> Message-ID: <20090526094923.GC1445@rwpc12.mby.riverwillow.net.au> On Tue, 26 May 2009, 10:29 +0200, Werner Koch wrote: > An older libgcrypt actually showed the problem: > > an mpi of size 0 is not allowed > an mpi of size 0 is not allowed > gpg: read_block: read error: Invalid packet > > thus finding the bug was easy after John sent me the full bad key. The > bug is due to an inconsistency between Libgcrypt and and GnuPG-1.4. > That problem must have been there for many years and will be fixed in > Libgcrypt 1.5.0. For the time being I implemented a workaround in > GnuPG. It is already commited SVN to trunk; find a patch below. Thank you Werner, I re-built GnuPG 2.0.11 with a patched parse-packet.c on one of my systems here and it now handles that key with no problem. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From bernhard at intevation.de Thu May 28 22:44:52 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 28 May 2009 22:44:52 +0200 Subject: pinentry debug-wait? Message-ID: <200905282244.53474.bernhard@intevation.de> Why isn't there a --debug-wait option in pinentry.c? It seems that if you set an "OPTION debug-wait" via assuan pinentry will wait for the debugger, but how is this helpful if gpg-agent calls several pinentries? I did not see in the source if there is a way to make gpg-agent give each pinentry this option. Is there? -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri May 29 13:23:59 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 May 2009 13:23:59 +0200 Subject: pinentry debug-wait? In-Reply-To: <200905282244.53474.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 28 May 2009 22:44:52 +0200") References: <200905282244.53474.bernhard@intevation.de> Message-ID: <87k540rw34.fsf@wheatstone.g10code.de> On Thu, 28 May 2009 22:44, bernhard at intevation.de said: > Why isn't there a --debug-wait option in pinentry.c? > It seems that if you set an "OPTION debug-wait" via assuan pinentry will wait > for the debugger, but how is this helpful if gpg-agent calls several This was introduced during the huge refactoring in March 2002. It was probably used along with ad-hoc modification in gpg-agent. The usual way to debug pinentry's interaction with gpg-agent is by using a wrapper script and optionally invoke it under debugger control. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.