ietf-openpgp
[Top] [All Lists]

Re: New results against SHA-1

2009-05-04 11:50:23
On 04/30/2009 06:39 PM, David Shaw wrote:

http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

There is not much hard information yet, but the two big quotes are
"SHA-1 collisions now 2^52" and "Practical collisions are within
resources of a well funded organisation."

Ugh.  i didn't think this would happen this soon.

I'd like to formally suggest that we need to re-open this working group
and begin discussion on a new revision of the OpenPGP draft.

Whether or not the above report turns out to have legitimate theoretical
grounding (i've only read the abstract, and don't know if my math would
be sufficient to evaluate a full report anyway), we know that there are
explicit dependencies on SHA-1 in OpenPGP that need to be made more
flexible.

Here are some key points that need to be adjusted w.r.t. digest algorithms:

 a) Fingerprints: these are currently SHA-1 hashes of the public key
mateerial.  One proposal is to continue hashing the exact same data but
to prefix the fingerprint with the canonical name of the digest
algorithm used, separated by an unambiguous delimiter (i'm using -
because : seems pretty overloaded in a lot of places, but i'm sure we
can collaboratively choose a good delimiter).  So in that case, my
current fingerprint would be re-written as:

 SHA1-0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

 b) fix the Revocation Key (subpacket 12) to indicate digest algorithm
and variable length data.  A poorly-worded attempt at a revision:

5.2.3.15.  Revocation Key

   (1 octet of class, 1 octet of public-key algorithm ID, 1 octet of
   digest algorithm, N octets of digest)

   Authorizes the specified key to issue revocation signatures for this
   key.  Class octet must have bit 0x80 set.  If the bit 0x40 is set,
   then this means that the revocation information is sensitive.  If bit
   0x20 is unset, the digest algorithm is assumed to be SHA-1, and no
   octet identifying the digest algorithm is included.  Implementations
   SHOULD set bit 0x20 and explicitly include the hash identifier.
   Other bits are for future expansion to other kinds of authorizations.
   This is found on a self-signature.

   If the "sensitive" flag is set, the keyholder feels this subpacket
   contains private trust information that describes a real-world
   sensitive relationship.  If this flag is set, implementations SHOULD
   NOT export this signature to other users except in cases where the
   data needs to be available: when the signature is being sent to the
   designated revoker, or when it is accompanied by a revocation
   signature from that revoker.  Note that it may be appropriate to
   isolate this subpacket within a separate signature so that it is not
   combined with other subpackets that need to be exported.

 c) settling on a new "lowest-common-denominator" hash aside from SHA-1
(or discarding the idea of a lowest-common-denominator hash?)

Some other possible changes:

 d) suggesting new defaults for key choices (does this mean avoiding
DSA1, for example, or other algorithms that rely on 160-bit hashes?)

 e) allow injection of arbitrary key material at the head of signatures
to allow signers to to avoid a chosen-prefix attack?  This would make it
significantly more difficult to predict the hash that someone will sign,
which makes birthday attack collisions more difficult to pull off since
the signer cannot be compelled to sign a particular hash.

 f) explicit introduction of new hashes/ciphers/asymmetric algorithms?


I've probably missed something.  What else should be addressed?  What
steps are necessary to get the WG back in order again?  Or is that not
needed?

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature

<Prev in Thread] Current Thread [Next in Thread>