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

[Jon Callas]

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