A coming attack on PGP, and a way to mitigate it

[Daniel Kahn Gillmor]

On 05/02/2009 01:42 AM, Daniel Franke wrote:
> A necessary precondition for this attack to succeed is that the contents
> of the packet that Trent signs be predictable.  Right now, they are.
> Guessing the signature creation time could be problematic, but if we're
> relying on that, then that's a hell of a way to run a cryptosystem.
> However, there's no reason this has to be so.  Without breaking backward
> compatibility, GnuPG could include in every signature packet a hashed
> 'Notation' subpacket containing a random nonce.  Now the SHA-1 digest
> that Trent signs is no longer predictable in advance, so if Mallory
> wants to find a collision, he needs a preimage attack rather than just a
> birthday attack.  This is much more difficult.

This is not a bad idea, and i think it is already possible, actually,
though not as easy to automate as it could be.  Maybe it would be
helpful to standardize on a name for the nonce notation as well?

Werner (or anyone else responsible for the gnupg.org domain), would
nonce at gnupg.org be acceptable for use?  Or if you're looking to isolate
the gnupg-related notation namsepace, maybe nonce at notations.gnupg.org ?

The way you could do this currently would be something like:

 NONCE="nonce at gnupg.org=$(head -c 20 /dev/random | base64)
 gpg --sign-key --set-notation "$NONCE" $KEYID

(note: use --sig-notation or --cert-notation if you only want this to
affect a data signature or key signature, respectively.  --set-notation
covers both)

So what's missing in terms of automation is the ability to get gpg to
automatically include a nonce or any other generated content.

for example, it'd be nice to be able to throw a line like this into
~/.gnupg/gpg.conf:

 set-notation nonce at gnupg.org=$(head -c 20 /dev/random | base64)

and have it do what i mean here.  If this embedding of shell output
seems too dangerous or crazy, another option would be to add to the
special codes in notations (gpg(1) implies that the special codes are
only used in notation names, but they seem to work in notation values as
well): perhaps %n would be a 160-bit nonce, base64-encoded?

Does anyone else think this feature would be useful?  I could take a
shot at writing a patch for either proposed behavior above if people are
interested.

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/20090503/a4f76b8b/attachment.pgp>