SHA-1 recommendations

[Daniel Kahn Gillmor]

On 05/17/2009 06:27 PM, Robert J. Hansen wrote:
> Daniel Kahn Gillmor wrote:
>> I think the proposed gpg.conf should also have "cert-digest-algo
>> SHA256" if people want to make sure their certifications (i.e.
>> signatures made over key+uid pairs) all use a stronger digest.
>> Without that setting, certificates will continue to be made with
>> SHA-1.
> 
> I am generally not a fan of altering this setting.  This will cripple
> interoperability with other OpenPGP applications that do not support
> SHA256 in certifications.  Again, though, if the consensus is for
> something different, I'll change the text.

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'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

Which is why i suggested the cert-digest-algo.

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

Either way, i think it should be addressed in these guidelines.

>> I think it's also worth explicitly recommending that the above 
>> configuration changes be made *before* generating a new key, so that
>> the specified changes affect the new key itself.
> 
> This only seems necessary if we use cert-digest-algo.  If we skip that,
> this seems unnecessary.

It's relevant if either cert-digest-algo or default-preference-list is
modified: the former affects the digest used to issue the self-sig, and
the latter affects the embedded pref-hash-algos subpacket in the self-sig.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090517/11ad51c0/attachment.pgp>