Re: Confusion with signature digest type.
On Thu, 2 May 2013 06:48, r...@sixdemonbag.org said: thinking of these problems, and if-and-when Werner and g10 Code decide to shift the default behaviors I'm certain it will be towards a stronger hash algorithm. We always tried to make sure that new algorithms are deployed for a long time before we make them the default. The next big change will be the switch to ECC and we not even have a real GnuPG release with. I expect that in a few years we can/need to switch to ECC and with that the end of signing SHA-1 digests will have come. Given that you need to create a new key anyway, the hash algorithm will be a non-brainer then. The special cases which Daniel constructed are, well, special cases and not the common use of signatures. People designing such a system should really consult with an expert to come up with a proper plan on how to implement that system. And that plan should include a discussion of used algorithms and threat models. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 04/28/2013 04:26 AM, Robert J. Hansen wrote: On 4/27/2013 8:01 PM, Daniel Kahn Gillmor wrote: I don't think this recommendation was made to defend against preimage attacks. Avoiding the use of SHA-1 in certifications in general is a step towards defend against collision attacks, which is territory that SHA-1 is heading into. (i agree that if sha-1 falls victim to preimage attacks we have much much bigger problems). I'm having a little bit of trouble connecting the dots, Daniel. (This may be due to the late hour: at 4:30am I'm only awake due to a caffeine IV.) If I sign my certificate using SHA-1 today, how does that facilitate a collision attack against that certification? It doesn't facilitate a collision attack against that specific certification; but if a collision attack is possible against a particular digest, then *any* signature made over that digest becomes suspect. That is, should a collision attack become viable against a particular digest, there's no way to tell whether any given signature that uses that digest was made before or after the collision attack was possible. So responsible clients that want to ensure that their certifications (including self-certifications) are acceptable to their more security-conscious peers should ensure that their certifications don't use digests that are at risk of collision attacks. For example, let's say you're in the habit of regularly signing a changing collection of data for $job, and those signatures use SHA1. An exploit comes along against SHA1 that renders it vulnerable to collision attacks. Eve manages to inject data into your collection that makes the data collection have the same digest as a particularly weird User ID when bound to your primary key (i'm handwaving past the details of the OpenPGP boilerplate involved in a self-sig here). Eve waits for you to make your regular data collection signature, and then rips it out and attaches it to your primary key, thereby creating an assertion that you have a new identity that you wish to be public and associated with your old ones. granted, this is not the end of the world (we all know that your e-mail address isn't really presid...@whitehouse.gov), but anyone who believes SHA-1-based certifications won't be able to tell whether rjh thinks he is the President of the USA or whether the President thinks he is rjh. You can avoid all of this by making all of your certifications (including your self-sigs) over a widely-accepted digest that is not thought to close to the risk of collision attacks; SHA-256 seems like a reasonable choice. There is no good reason for anyone interacting with modern infrastructure to make their default certifications with anything weaker. For the few people who need to ensure that their key can be accepted by legacy systems that don't support SHA-256, systems that want to be legacy-compatible could issue each self-sig in duplicate form: one using SHA1, timestamped at N-1 seconds since the epoch, and the other using SHA256, timestamped at N seconds since the epoch. Modern tools that can interpret the SHA256 certification would use it (and ignore the older cert that uses the weaker digest) and legacy SHA2-incapable systems could interpret the older cert. does this make the concern (and one approach to addressing it) more clear? Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 5/1/2013 10:16 PM, Daniel Kahn Gillmor wrote: It doesn't facilitate a collision attack against that specific certification; but if a collision attack is possible against a particular digest, then *any* signature made over that digest becomes suspect. First, thank you for a thorough reply. I appreciate it a great deal. I think we may be using two different definitions of collision attack. That is, should a collision attack become viable against a particular digest, there's no way to tell whether any given signature that uses that digest was made before or after the collision attack was possible. In the absence of a trusted timestamp, yes. (Of course, then this becomes a question of whether the trusted timestamp is susceptible to attack. I concede that this isn't a solution but just a reification one level deeper.) Eve manages to inject data into your collection that makes the data collection have the same digest as a particularly weird User ID when bound to your primary key (i'm handwaving past the details of the OpenPGP boilerplate involved in a self-sig here). Are you sure that this is a collision attack? It seems to me you've created a preimage scenario here. And if so, I stand by my statement of then I'm completely screwed on a dozen different fronts simultaneously and my certificate is the least of my worries. :) (For those confused by the difference -- I'm certain Daniel isn't -- all preimage attacks are collision attacks, but relatively few collision attacks are preimage attacks. Wikipedia defines a collision attack as being able to find two arbitrary different messages m1 and m2 such that hash(m1) = hash(m2). The 'arbitrary' is important: you only care about finding a collision, but you don't care one whit what that collision is over. By comparison, a preimage attack means finding a specific message that hashes out to a specific value. By manipulating the data I'm signing, Eve is finding a specific message: by specifying it must hash out to the same as a signature he made in the past, Eve is specifying a particular hash value. This is why his scenario seems to me to be a preimage attack in disguise, rather than a collision attack.) (However, it is certainly possible that I've misunderstood his scenario.) There is no good reason for anyone interacting with modern infrastructure to make their default certifications with anything weaker. I continue to think that you're worrying about how you're going to turn the coffeepot off as you're fleeing a house fire. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 05/02/2013 12:03 AM, Robert J. Hansen wrote: Eve manages to inject data into your collection that makes the data collection have the same digest as a particularly weird User ID when bound to your primary key (i'm handwaving past the details of the OpenPGP boilerplate involved in a self-sig here). Are you sure that this is a collision attack? It seems to me you've created a preimage scenario here. And if so, I stand by my statement of then I'm completely screwed on a dozen different fronts simultaneously and my certificate is the least of my worries. :) if it was a preimage attack (even for SHA1), then yeah, it'd be game over in a lot of horrible ways i don't want to think about in detail right now :) It's a collision attack based on the idea that: a) Eve can inject arbitrary data into the collection that she expects you to sign, and b) Eve can inject arbitrary data into the self-sig that she's crafting (e.g. in a tumor in non-critical subpackets of the Eve-generated self-sig). So Eve's work is to manipulate both X (the data repository) and Y (the self-sig she's crafting) until she can coax them into a collision. She doesn't care what the collision is, so she's not involved in a pre-image attack. As i understand it, this is roughly analogous to the attack used against rapidssl in http://www.win.tue.nl/hashclash/rogue-ca/, which exploited cryptogrpahic weaknesses in MD5's collision resistance to mint an exploitable intermediate CA. In that attack, they manipulated X (the expected serial number and timestamp and distinguished name in the X.509 cert generated by RapidSSL) and Y (the tumor in their bogus, handcrafted intermediate X.509 CA cert) until they found an MD5 collision, and then got RapidSSL to issue the predictable cert at the expected timestamp with the expected serial number. Once the X.509 cert was issued, they spliced the good signature onto the bogus cert, and had themselves a cert that any browser would accept. If you think this analogy doesn't hold, please let me know where it falls apart. There is no good reason for anyone interacting with modern infrastructure to make their default certifications with anything weaker. I continue to think that you're worrying about how you're going to turn the coffeepot off as you're fleeing a house fire. :) I still maintain that encouraging people to use SHA-1 for any certification (including self-sigs) is leaving the coffeepot on, but the house is not yet on fire. Let's turn off the coffeepot :) SHA-1 is a fine digest for fingerprints, which are generated from material entirely under the user's control, and cannot be influenced by an outside party, and can never be confused or substituted by such things. this is because fingerprints rely on preimage resistnace, But it is ill-advised to make new signatures over any digest that has significantly weakened collision-resistance; this is particularly true when stronger digests are widely available, as is the case with SHA-256. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 5/2/2013 12:33 AM, Daniel Kahn Gillmor wrote: if it was a preimage attack (even for SHA1), then yeah, it'd be game over in a lot of horrible ways i don't want to think about in detail right now :) I think I can make a compelling argument this is a preimage attack and not a collision attack, and I think I can sum it up in one sentence: So Eve's work is to manipulate both X (the data repository) and Y (the self-sig she's crafting) until she can coax them into a collision. She doesn't care what the collision is, so she's not involved in a pre-image attack. She cares what the collision is: it has to be a valid OpenPGP signature sequence. I concur that this scenario is deeply troubling. However, I think the scenario as you've described it depends on a preimage attack and at that point, as we've agreed, we're all screwed. (As a comment for people who may be thinking Daniel and I are vehemently disagreeing: sure, we don't agree, but I think we're far, far closer to agreement than discord.) I still maintain that encouraging people to use SHA-1 for any certification (including self-sigs) is leaving the coffeepot on, but the house is not yet on fire. Let's turn off the coffeepot :) Oh, please don't misunderstand me, I'm not encouraging the continued use of SHA-1. I'm simply not encouraging the wholesale migration to SHA256, not at this point in time. (Encouraging people to have a plan, though, sure.) As a general rule, I've found the GnuPG developers to be quite capable of coding sensible default behaviors. I expect that Werner has been thinking of these problems, and if-and-when Werner and g10 Code decide to shift the default behaviors I'm certain it will be towards a stronger hash algorithm. In my experience, there is no such thing as a painless tradeoff. The instant you encourage someone to deviate from the defaults you open the door to a flood of questions. Some of them are quite reasonable (why should I use SHA256 when SHA512 is available?) and some show their authors started sniffing glue at a tender age. The only constant is that the instant you tell someone to mess with the defaults, any and all future problems they have are suddenly your fault and your responsibility to solve. I don't see the situation with SHA-1 is so dire that we need to jump the gun on GnuPG's natural migration towards stronger hash algorithms. Given that, and given that I don't want to field a ton of I changed my .gnupg file just the way you said and it doesn't work type of questions, well -- I concur that moving to better hash algorithms is the way to go. I'm unconvinced that the situation right now is so dire that we need to leapfrog GnuPG's development process. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 5/2/2013 12:48 AM, Robert J. Hansen wrote: She cares what the collision is: it has to be a valid OpenPGP signature sequence. Erf, did I really write that? s/signature/User ID The point being the User ID isn't allowed to be completely arbitrary: there's a lot of structure to it. I think that's what kicks this into a preimage. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 05/02/2013 12:51 AM, Robert J. Hansen wrote: On 5/2/2013 12:48 AM, Robert J. Hansen wrote: She cares what the collision is: it has to be a valid OpenPGP signature sequence. Erf, did I really write that? s/signature/User ID The point being the User ID isn't allowed to be completely arbitrary: there's a lot of structure to it. I think that's what kicks this into a preimage. the same can be said of X.509 certificates. there is a lot of structure in them too, but nonetheless a collision attack was sufficient to mint a new certificate from rapidSSL's predictable signing policy. The User ID itself does have well-defined structure, it's true -- in particular, it has to be a valid UTF-8 bytestream. However, the selfsig is made on a digest over many things, only one of which is the User ID. for example, it could contain an arbitrary OpenPGP notation subpacket, which can itself include an arbitrary bytestream in the value field, particularly if notation flag 0x80 is cleared. Compare this to the X.509 ASN.1 tumor used in http://www.win.tue.nl/hashclash/rogue-ca/ This is an attack against the digest's collision-resistance, not against its preimage resistance. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 4/27/2013 8:01 PM, Daniel Kahn Gillmor wrote: I don't think this recommendation was made to defend against preimage attacks. Avoiding the use of SHA-1 in certifications in general is a step towards defend against collision attacks, which is territory that SHA-1 is heading into. (i agree that if sha-1 falls victim to preimage attacks we have much much bigger problems). I'm having a little bit of trouble connecting the dots, Daniel. (This may be due to the late hour: at 4:30am I'm only awake due to a caffeine IV.) If I sign my certificate using SHA-1 today, how does that facilitate a collision attack against that certification? Collision attacks on SHA-1 seem to be more in the realm of message signatures and automated systems that may generate a ton of signatures on user-provided data without human intervention. It doesn't seem to be particularly relevant to the case of a certificate signature: it seems as if to attack that you'd have to move from generating random collisions into preimage attacks. It is, of course, quite possible that I'm tired and missing something important. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 04/26/2013 11:47 AM, Robert J. Hansen wrote: For my own lookout, I don't see that this practice would give me very much. If SHA-1 falls victim to preimage attacks I don't think this recommendation was made to defend against preimage attacks. Avoiding the use of SHA-1 in certifications in general is a step towards defend against collision attacks, which is territory that SHA-1 is heading into. (i agree that if sha-1 falls victim to preimage attacks we have much much bigger problems). That is: if SHA-1 becomes vulnerable to collision attacks, you'd like to update as many OpenPGP clients as possible to avoid relying on signatures made over an SHA-1 digest. If (when?) that transition happens, everyone whose self-sigs are made using SHA-1 will find their keys considered invalid by updated clients because they have no correctly-bound User ID. So ensuring that your self-sig uses a stronger digest than SHA-1 is worth doing because it prepares you for such a transition. --dkg PS MD5 *is* vulnerable to collision attacks (and has been actively exploited [0]), and those attacks are cheaper to execute with each passing year. At the moment, gpg still accepts certifications made over MD5, which arguably makes it vulnerable to compromise in the same way that regular web browsers that accepted MD5 certs were vulnerable to the bogus CA created in [0]. For example, if you place ultimate trust in Gene Gotimer's key 0x7833F0F5, then gpg is willing to rely on an MD5-based certification made by that key to prove identity validity: 0 dkg@alice:/tmp/cdtemp.b9QnBL$ gpg --list-options show-uid-validity --list-keys ./pubring.gpg - pub 1024R/7833F0F5 2000-02-01 uid [ultimate] Gene Gotimer goti...@portinfo.com pub 1024D/DB42A60E 1999-09-23 uid [ full ] Red Hat, Inc secur...@redhat.com sub 2048g/961630A2 1999-09-23 0 dkg@alice:/tmp/cdtemp.b9QnBL$ gpg --with-colons --check-sigs secur...@redhat.com | grep -v ? tru::1:1367047560:0:3:1:5 pub:f:1024:17:219180CDDB42A60E:1999-09-23:::-:Red Hat, Inc secur...@redhat.com::scaESCA: sig:!::17:219180CDDB42A60E:1999-09-23Red Hat, Inc secur...@redhat.com:13x: sig:!::17:219180CDDB42A60E:1999-09-23Red Hat, Inc secur...@redhat.com:13x: sig:!::1:B272C7707833F0F5:2002-07-18Gene Gotimer goti...@portinfo.com:10x: sub:f:2048:16:C9CC699F961630A2:1999-09-23::e: sig:!::17:219180CDDB42A60E:1999-09-23Red Hat, Inc secur...@redhat.com:18x: 0 dkg@alice:/tmp/cdtemp.b9QnBL$ The only warning a gpg user gets is that this is happening (if they're not careful) is two lines during key import that says: gpg: WARNING: digest algorithm MD5 is deprecated gpg: please see http://www.gnupg.org/faq/weak-digest-algos.html for more information It does not indicate which certification(s) in particular is using MD5, or that gpg is actually accepting that certificate when doing its WoT calculations. [0] http://www.win.tue.nl/hashclash/rogue-ca/ signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 4/26/2013 5:47 AM, Robert J. Hansen wrote: For my own lookout, I don't see that this practice would give me very much. If SHA-1 falls victim to preimage attacks then I'm completely screwed anyway on a few dozen fronts simultaneously, and my certificate is the least of my worries. If I wake up in the middle of the night and discover my house is on fire I'm not going to care very much about whether I forgot to turn off the coffeepot. A preimage attack on SHA-1 is my house being on fire: avoiding SHA-1 for self-signatures is making sure to turn off the coffeepot. I suspect that quite a lot of us are in that same boat. Indeed. SHA-1 is used pretty much everywhere. If preimage attacks for SHA-1 become practical a *lot* of stuff will be affected. That said, it certainly isn't a bad idea to being gracefully transitioning away from SHA-1. For existing keys it's probably not a major issue (there's still a *ton* of 1024-bit DSA keys with SHA-1 in the wild), but it'd probably make sense for new keys to be generated with stronger defaults (e.g. SHA-256 or higher and, once implemented, SHA-3) and to also use those stronger hash algorithms for things like certifying keys. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Apr 25, 2013 at 11:47:49PM -0400, Robert J. Hansen wrote: A preimage attack on SHA-1 is my house being on fire: avoiding SHA-1 for self-signatures is making sure to turn off the coffeepot. While I agree with what you're saying, the big difference between this situation and your example is that it's trivially easy for me to say use this digest method instead of this other one and then forget about it. The coffee pot will take care of itself. The question becomes invisible to me as soon as I've set the default, and if the effort is so low to do it, I don't see any real reason *not* to do it. Security is about nudging up the bar. Now, that said, I still don't understand why I was seemingly unable to change the digest algorithm I'm using for my old key. I'd be grateful if someone could enlighten me on that point, as I really want to grasp what was happening. - -- Mason Loring Bliss ma...@blisses.org Ewige Blumenkraft! $awake ? $sleep : int rand 2 ? $dream : $sleep; -- Hamlet, Act III, Scene I -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJReqi+AAoJEJ6yV3B27yVVeWEQAM8Zq23t23ZPUWylHDttflrR h/gqg2QQd1VUeOiIdjUebrWfq7wREj2w+quO3mnIipoGIkloTBtSWfuoXz6Molnl n+y1ye5/EcyNpsEWJmeilwg8WhxLvc1KiFzbB50dbeg5KEasTKR1vs0tQ3+cPZho ItfhnaxGWsSTVt5y4i7Ulqn7bPeXk0EjDOXHGKlPQI334/qgU+4wCs/cDK1o5uux 1bpgewvpea63q2O3d8b5xNl6INwdmPlTsl1DOUanIvD9I6TAEeD5YM6d8u/wPl7A k7U4qf0PbhCcK5SvjdXQRFc1w50SzPgNuQSHgbIHD5zD7tzfN7elHH5i0+zRXF/W wIBnzBDfZzVYgJgCc7OgfjyMe2aCpPml8hPCwBBN8l49EivUbgVvTXY9caGPA/zE Sq24QuChpUmPeNpO5aFhcmZHwhce2en28uryaOpmXZddHO5HTROBwkOPFhx51cHB g8ywoz/dvjcwmTwDgN23xBD/WBkaEUfrmzwdlywv3ldZNvduy1YamHrBEwNY61Hb M6cw/7buYlBv9hcXfiVaA1GtNBCJ/ASGlC9Mp3dwgCuhJ2kcPKVucmBo8z2uGJ8w UPm9bYqgs91eodUT1DxKEv+e18+h+PVRIYXd65fhPiBjfZ2ja+2hE6q5Xj9czhfP OsGxVaeV1D57CNkkxbzo =V6uB -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On Apr 26, 2013, at 12:18 PM, Mason Loring Bliss ma...@blisses.org wrote: On Thu, Apr 25, 2013 at 11:47:49PM -0400, Robert J. Hansen wrote: A preimage attack on SHA-1 is my house being on fire: avoiding SHA-1 for self-signatures is making sure to turn off the coffeepot. While I agree with what you're saying, the big difference between this situation and your example is that it's trivially easy for me to say use this digest method instead of this other one and then forget about it. The coffee pot will take care of itself. The question becomes invisible to me as soon as I've set the default, and if the effort is so low to do it, I don't see any real reason *not* to do it. Security is about nudging up the bar. Now, that said, I still don't understand why I was seemingly unable to change the digest algorithm I'm using for my old key. I'd be grateful if someone could enlighten me on that point, as I really want to grasp what was happening. The answer to your question from your original mail is that you're using the check if SHA-1 is in my preferences test to instead of the check if my selfsig is SHA-1 test. The proper test for checking your selfsig from the document you were referencing is: gpg --export-options export-minimal --export keyid | gpg --list-packets |grep -A 2 signature|grep 'digest algo 2,' David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 26/04/13 03:13, Mason Loring Bliss wrote: gpg --export-options export-minimal --export keyid | gpg --list-packets | grep 'pref-hash-algos' ...I see algorithm 2 still there. I think you're mixing things up. pref-hash-algos is the algorithms you'll accept from others. The page you linked to mentioned this to test if you use SHA-1 as the self-signature digest algo: gpg --export-options export-minimal --export keyid | gpg --list-packets |grep -A 2 signature|grep 'digest algo 2,' (should be one line) The pref-hash-algos is the next section of the document. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confusion with signature digest type.
On 4/26/2013 12:18 PM, Mason Loring Bliss wrote: While I agree with what you're saying, the big difference between this situation and your example is that it's trivially easy for me to say use this digest method instead of this other one and then forget about it. Sure: but what does it gain you? The answer would seem to be, on the balance of probabilities, virtually nothing. All the hash algorithms in OpenPGP are mathematically similar. They're all built around Merkle-Damgard constructions. History shows us that when there's a successful attack against one Merkle-Damgard construction, quite often this attack spurs new equivalent attacks against other hashes in the Merkle-Damgard family. This is one of the reasons why so few people recommend RIPEMD-160, for instance: despite the fact that there are no effective attacks against it, the consensus opinion seems to be that RIPEMD-160 is just too similar to SHA-1 and MD5 for there to be real confidence in it. Let me repeat: *all* the hash algorithms in OpenPGP are Merkle-Damgards. So if there's not just a collision attack against SHA-1, but a preimage attack, well... are you really going to have any confidence in your signatures just because you're using SHA-256? I wouldn't. A preimage attack on SHA-1 would tell me the entirety of the Merkle-Damgard family is suspect and I need to stop using them immediately. Security is about nudging up the bar. Yes: and is what you're talking about really a nudge? Or is it an act that appears to be a nudge, while in reality achieving effectively zero? (Note that I'm not expressing doubt. You're the one who knows your threat model, not me. If you tell me that yes, this is a real nudge up, then that settles the question. I'm only raising a question: I am entirely apathetic as to the answer.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
