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-23::::Red Hat, Inc > <secur...@redhat.com>:13x: > sig:!::17:219180CDDB42A60E:1999-09-23::::Red Hat, Inc > <secur...@redhat.com>:13x: > sig:!::1:B272C7707833F0F5:2002-07-18::::Gene Gotimer > <goti...@portinfo.com>:10x: > sub:f:2048:16:C9CC699F961630A2:1999-09-23::::::e: > sig:!::17:219180CDDB42A60E:1999-09-23::::Red 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