David Shaw writes:
On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote:
We might want to think about making SHA-256 be another MUST algorithm.
The only MUST hash now is SHA-1. Making SHA-256 be a MUST would make
these new key sizes be more useful, and also give us an easier fallback
if SHA-1 should be broken.
Unless DSA2 is also a MUST, I wonder what the practical advantage to
that would be (beyond making the social point that we really, really
want people to move away from SHA-1). Since an OpenPGP program would
not necessarily know whether the recipient could handle SHA-256
(SHA-256 dates from around 2004, implementation-wise), it would have
to use SHA-1 in many or most cases anyway. Obviously a DSA2 signature
wouldn't be expected to work, but an RSA signature would have this
problem, and DSA1 (using a truncated SHA-256) would have the problem
as well for both truncation and SHA-256 reasons.
OK, but maybe a "SHOULD" like Werner suggested, then?
A few months back you asked the question whether new DSAs would best
be supported by extending the definition of the current DSA, or by
assigning a new algorithm ID for DSA2. At the time, most people
(myself included) felt that extending the current DSA would be the
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).
At this point I like the idea of keeping the same algorithm ID. All the
code and algorithms are the same, so using a different alg ID just
for different key sizes doesn't really make sense. Using a different
algorithm ID will be, from the future perspective, a historical artifact.
And I don't see that it really helps interoperability to use a new ID.
Either way, the bottom line is that old code won't work with the new
keys and new code will. Plus it makes implementation of the change a
lot easier - granted, a minor point, but on top of everything else I
see this as the preferable strategy.
I also think we should change the names of SHA256 etc to use dashes
as in SHA-256; those are the official names.
To be clear here: are you referring to changing the descriptive text
in the draft or changing the hash name strings as used in clearsigned
message "Hash:" headers? The first is easy and I agree should be
done, the second has compatibility implications.
Just in the draft, then. I guess we're stuck with the name strings.
It's not a big deal either way.
Hal Finney