SHA-1 recommendations

[David Shaw]

On May 17, 2009, at 8:36 PM, Daniel Kahn Gillmor wrote:

> This is a difficult tradeoff.  Certifications themselves seem to be  
> the
> most likely place in the whole OpenPGP architecture where a keyholder
> will be signing material that is provided by a potential adversary.
>
> For example, if i meet Alice at a keysigning party, Alice provides me
> with a large chunk of fairly opaque data (her public key material,  
> maybe
> possible to use as a carrier for collision-specific perturbations?),  
> one
> or more User IDs (textual, more difficult to hide perturbations in),  
> and
> zero or more user attributes (JPEGs, which i think are relatively  
> simple
> to perturb in ways that the signer can't be reasonably expected to  
> detect).

I would wager that IF an OpenPGP certification specific SHA-1  
collision attack eventually appears, it would appear for photo IDs  
first.  There are a huge number of ways to twiddle bits in a JPEG (the  
thing supports *comment fields* for crying out loud) in ways that  
aren't visible in the image itself.

Incidentally, I don't sign photo IDs.  It has nothing to do with this  
theoretical attack - a photo ID does not make a statement that I am  
willing to certify.

> I'm expected to issue one signature per UID (over key+uid) and per UAT
> (over key+uat), and the bitstream for each of these signatures is
> entirely specified by Alice.  I can add subpackets to the hashing
> context *after* the material specified by Alice after i've signed it.
> But if Alice has found a collision, and her key+uat is "part A" of the
> collision, she can just append my provided subpackets to "part B" to
> preserve the digest collision.
>
> This makes me tend to concur with David Shaw we should stop making
> signatures over SHA-1 now:
>
>  http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025048.html

I do think that people should stop issuing SHA-1 certifications, but  
there are other considerations that need to be taken into account here  
- not all clients can handle those signatures, and I don't think we're  
at the point where defaults should be changed.  It's not a black or  
white situation.

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.

>> If the preference list is really a capability set, then
>> default-preference-list is fine as-is.  We prefer to use SHA256, we
>> advertise we can use SHA256, there's no problem.
>
> If it's a capability list, it's currently incorrectly set because the
> OpenPGP client used by the keyholder (gpg, in this case), has many  
> more
> capabilities than those listed, including the longer digests in the
> SHA-2 family.
>
> If it's an ordered list of preferences, i think it's incorrectly set
> because we should be advertising our preference for stronger digests
> above SHA-1.

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.  ;-)

David