On 20 Feb 2006, at 7:44 PM, Tony Hansen wrote:
I don't like being a guinea pig, but that's what it feels like with
the
discussions on how to go about upgrading algorithms. I don't think we
know enough yet to even know how to begin. This is a problem that a
variety of protocols are going to go through, so we are *not* alone
(and
*shouldn't* be alone) in trying to figure out how to do it.
Could we invite people in from SAAG to form a design team, investigate
the problem, then come in and tell us how to go about doing it, or at
least to give us some ideas? I know we don't usually do
presentations at
WG meetings, but this topic might be worthy of one. So I'm suggesting
that we put "how to go about upgrading the hash algorithm" on the
agenda
for the IETF meeting.
Oh, please no. This has been talked to death over the last year and a
half.
We know what to do. The *technical* aspects of how you upgrade a hash
algorithm are well-known, and not that hard. It's not like hash
algorithms are magical. The problem is basic things like people hard-
coding lengths into the system.
The *real* problem is that there is no pristine option. Everyone
believes that the obvious candidate, SHA-256, is flawed, but no one
knows how. There aren't any other real viable options, other than
SHA-256. (Ah, but what about Whirlpool, I hear you ask. The only
problem with Whirlpool is that it is slow. It runs at about half the
speed of SHA-256, which happens to be about the speed of SHA-512.
Which means that the only reason to use it over SHA-512 is in a
situation where the difference in size matters and you need a small
hash.)
There is nothing that SAAG or anyone else can do for us. We happen to
be living in a time where we *know* that the cryptographic primitives
we have handy in our toolkit are not what we like. We live in what
the Chinese and Scots each call "interesting times."
The only question facing us is whether we jump straight to SHA-256
now, or allow both. Jumping is cryptographically wiser as it gets us
off the weak hash. Allowing both is engineeringly wiser as it forces
us to be agile now. Neither is a bad choice, sadly. If one were a bad
choice, then it would be easy. As things sit, we have a hard choice,
and no matter what we do, people will look back with the wisdom of
hindsight and cluck their tongues sadly about how stupid we were and
how *clearly* it would have been better to do the other thing.
Jon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html