Confusion with signature digest type.

[Daniel Kahn Gillmor]

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 at alice:/tmp/cdtemp.b9QnBL$ gpg --list-options show-uid-validity --list-keys
> ./pubring.gpg
> -------------
> pub   1024R/7833F0F5 2000-02-01
> uid       [ultimate] Gene Gotimer <gotimer at portinfo.com>
> 
> pub   1024D/DB42A60E 1999-09-23
> uid       [  full  ] Red Hat, Inc <security at redhat.com>
> sub   2048g/961630A2 1999-09-23
> 
> 0 dkg at alice:/tmp/cdtemp.b9QnBL$ gpg --with-colons --check-sigs security at redhat.com | grep -v ?
> tru::1:1367047560:0:3:1:5
> pub:f:1024:17:219180CDDB42A60E:1999-09-23:::-:Red Hat, Inc <security at redhat.com>::scaESCA:
> sig:!::17:219180CDDB42A60E:1999-09-23::::Red Hat, Inc <security at redhat.com>:13x:
> sig:!::17:219180CDDB42A60E:1999-09-23::::Red Hat, Inc <security at redhat.com>:13x:
> sig:!::1:B272C7707833F0F5:2002-07-18::::Gene Gotimer <gotimer at portinfo.com>:10x:
> sub:f:2048:16:C9CC699F961630A2:1999-09-23::::::e:
> sig:!::17:219180CDDB42A60E:1999-09-23::::Red Hat, Inc <security at redhat.com>:18x:
> 0 dkg at 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130428/57f948cd/attachment.sig>