[ietf-dkim] agenda item on upgrading hash algorithms?
ned.freed at mrochek.com
Wed Feb 22 15:42:41 PST 2006
> > 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
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
> 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.
More information about the ietf-dkim