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 [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
