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
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel gnupg.org
h
ttp://lists.gnupg.org/mailman/listinfo/gnupg-devel
|