> 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.
Indeed it has.
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.
Yes, this is certainly one source of trouble. I think we've been
careful not to make these sorts of size assumptions in our code, but you're
never sure until you get in there and add the support.
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."
Yes, and complaining about the current state of affairs and how
we got here may be somewhat cathartic but in the end accomplishes nothing.
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.
Very nicely put. I completely agree. It should be obvious that I'm in the
"might as well get agility correct now" camp, no doubt because I'm an
implementor first and I've been bitten too many times by bad code and bad
assumptions built into code. But the SHA-256 only position definitely
has merit too.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html