DSA2 and recipient preferences

[David Shaw]

On Sat, Jun 03, 2006 at 10:33:10PM +0200, Qed wrote:
> Playing with DSA2 keys(gnupg 1.4.4-svn4149) I've noticed a potentially
> problematic behaviour when mixing old and new keys.
> 
> Suppose you have three keys:
> # <mybigDSA2> is your key and is a 3072DSA(q=256)
> # <recentKEY> is a key that has the following digest prefs: SHA1,
> SHA256, RIPEMD160
> # <oldKEY> is a key with the following(rather common) digest prefs:
> SHA1, RIPEMD160
> and you have personal-digest-preferences "H10 H9 H8 H3 H2" in your
> gpg.conf.
> 
> with "gpg -u <mybigDSA2> -s -e --encrypt-to <mybigDSA2> -r <recentKEY>"
> we obtain a DSA/SHA256 signature, correct.
> 
> with "gpg -u <mybigDSA2> -s -e --encrypt-to <mybigDSA2> -r <oldKEY>"
> we obtain a DSA/SHA512(truncated to 256bits) signature without ANY warning.
> 
> with "gpg -u <mybigDSA2> -s -e --encrypt-to <mybigDSA2> -r <recentKEY>
> -r <oldKEY>"
> again we obtain a DSA/SHA512 sig without warnings, thus violating the
> preferences of both recipients.

Not a bug, just a no-way-out situation.  You told GPG to sign using a
q=256 key, so the hash has to be 256 bits or larger.  At the same
time, you told GPG that it had to use either SHA1 or RIPEMD160, both
of which are 160 bits.  In the case where GPG simply cannot come up
with a hash that pleases everyone, it goes with what the signing key
is capable of (i.e. 256 or larger) joined with your
personal-digest-prefs.  Thus it chose SHA512: larger than 256 bits so
the signing key was happy, and 512 because you listed it first.

I sympathize about the desire for a warning message here, but remember
that this would mean a warning message for almost every signature made
with a DSA2 key.  Any time you have a DSA2 key signing and encrypting
to an older key without SHA256 (which are a significant majority of
keys at this point) you would get a warning.  In such a situation,
warnings become meaningless.

> This latter behaviour is obviously a bug, RFC2440 says about symmetric
> ciphers:
> > An implementation MUST NOT use a symmetric algorithm that is not in
> > the recipient's preference list. When encrypting to more than one
> > recipient, the implementation finds a suitable algorithm by taking
> > the intersection of the preferences of the recipients.
> but future DSA keys with q>160 would inevitably break this rule when the
> recipient is a key with digest prefs set to "H2 H3".
> Decrypting the message with such a key and veryfing doesn't generate any
> warning, again RFC2440:
> > If an implementation can decrypt a message that a keyholder doesn't
> > have in their preferences, the implementation SHOULD decrypt the
> > message anyway, but MUST warn the keyholder that the protocol has
> > been violated.
> 
> Obviously my statements are based assuming that the same considerations
> for symmetric algorithms apply to digest algorithms, section 12.2 says:
> > Other algorithm preferences work similarly to the symmetric
> > algorithm preference, in that they specify which algorithms the
> > keyholder accepts.
> 
> Must be said that section 12.2.2(Hash algorithm preferences) doesn't
> specify explicitly what MUST be done, so if my assumptions are wrong,
> please ignore me.

They're "similar," but not identical.  Cipher preferences are agreed
upon between the sender and recipient.  Digest preferences are merely
suggested by the recipient.  Ultimately, the signer has to choose as
it is the one issuing the signature.  In the past, there was always
SHA1 - the must have digest - that could be used as a fallback, so
this problem never really happened in practice.  Now with DSA2, it's a
possibility.

With DSA2, the recipient may not have *any* of the digests needed by
the sender.  The choice then becomes to let the sender pick a digest
the recipient can't handle, or... don't sign at all.

Thanks for testing DSA2.  This was an interesting interaction between
the new and old keys and it is good to get discussion of it before
DSA2 is released in GPG 1.4.4 and the floodgates open ;)

David