On Fri, Mar 17, 2006 at 04:54:21PM +0100, Werner Koch wrote:
On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said:
right answer. Now that we have actual information about DSA2, perhaps
it would be worth revisiting that question. A new algorithm ID for
DSA2 resolves a number of problems in one fell swoop as there is no
expectation of interoperability. SHA-256 is always usable
(effectively the default) for DSA2, and there is no problem with
knowing when it is possible to use truncation (always).
Sounds good to me.
I support this too. The majority of keys are DSA keys q=160 bit.
Having a new algorithm indentifier will help more than harm.
Even though I originally brought it up, I've given this a good bit of
additional thought while mailing with Hal on the list yesterday, and I
think it really does come down to something as simple as a question of
error messages. I'm not for a new algorithm ID.
It breaks down like this:
1) a q==160 signature without truncation (hash size matches q exactly)
2) a q==160 signature with truncation (hash left-truncated to match q)
3) a q!=160 signature without truncation (hash size matches q exactly)
4) a q!=160 signature with truncation (hash left-truncated to match q)
I'm not mentioning the larger key size in DSA2 as I believe that
deployed code will handle larger DSA key sizes correctly.
Obviously #1 isn't a problem, as it is what DSA is today. I think PGP
can actually do #2, but for the sake of argument, let's say that
nobody can do #2, #3, or #4 on current code.
If we don't assign a new algo ID for DSA2, #3 and #4 will fail because
of the wrong q size, and #2 will fail because of the truncation. If
we do assign the new ID, as before #2, #3, and #4 will fail - but so
will #1! Even though the signatures are compatible, the new algo ID
will cause the signature to fail on the older implementation. This
argues against a new algo ID. Even if we don't create DSA2 q=160 keys
(internally changing them to DSA1 keys), this just returns the
question to neutral, and the extra code complexity and questions (will
it break any keyservers? It will certainly break pksd) of assigning
the new algo ID argue against it.
David