SHA-1 recommendations

[David Shaw]

On May 18, 2009, at 11:14 AM, Daniel Kahn Gillmor wrote:

>> So, while I personally am issuing SHA-256 key certifications (and  
>> have
>> been for a while), I do not think that switching the default away  
>> from
>> SHA-1 is appropriate at this time.  What is good for me is not
>> necessarily what is good for the whole world.
>
> Understood.  We're not discussing changing the defaults here, though,
> we're discussing Robert J. Hansen's proposed document for people who  
> are
> interested in mitigating whatever risks may be implied by a  
> progressive
> weakening of SHA-1.

Understood, but I believe the quote from me that was used was from  
that context, so I wanted to make that context clear.  I don't really  
favor this sort of "here's how to transition everyone" document.

> Here's an idea: trawl the public keyservers, and look at the  
> proportion
> of valid (non-expired, non-revoked) keys with digest preference
> subpackets in their self-sigs which mention any digest from the SHA-2
> family.  It would be good to rule out abandoned keys somehow; doing so
> is probably fundamentally impossible, but maybe we could approximate  
> it
> by discarding keys with no certifications attached in the last 5  
> years?

Not all users of OpenPGP use the keyservers or even participate in the  
web of trust.  It's also used in various environments where keys are  
traded manually.

>> I see no conflict in the RFC:  the list is ordered, and a random
>> selection is perfectly conformant.  The list is ordered to give
>> implementations that want to do something useful with rankings  
>> something
>> to work with (and note that both of the "big two" of PGP and GPG  
>> order
>> their lists to varying degrees), but those implementations that do  
>> not
>> want to play with rankings are allowed to pick however they like.   
>> It's
>> similar, in a way, to the IETF meta-rule: be conservative in what you
>> generate, be liberal in what you accept.
>>
>> So it's an ordered list of capabilities.  Or perhaps a capability  
>> set of
>> preferences.  ;-)
>
> I'm not suggesting there is a conflict in the RFC, simply that it  
> seems
> that GnuPG could use a refresh of its default digest preferences.

No, I was agreeing with you.  Robert saw a conflict, but I don't.

> * include the stronger SHA-2 digests which gpg supports, and
>
> * re-order them in a clearly-stated way (i.e. commit to saying "gpg
> interprets and produces the orderings as preferential, with most- 
> desired
> first"), and explicitly, publically prefer digests from the SHA-2  
> family
> over SHA-1.

I don't have a problem with this.   GPG does interpret the ordering as  
preferential (is there some source that says otherwise?).  The current  
default hash preference list is "SHA1 SHA256 RIPEMD160".  It's simple  
enough to juggle the list so that SHA256 comes first, etc.  I wouldn't  
want to put that into some extra document, though: it's a fairly  
small, and quite safe change.  I'd support changing the default for  
that.

David