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