ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

2006-02-22 12:30:45

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