Re: [ietf-dkim] Supporting alternate algorithms

On 20 Feb 2006, at 3:09 PM, Daniel Dreymann wrote:

> I concur. Last week I used the opportunity of the RSA conference to  
> conduct
> an informal survey with many of the world's best known  
> cryptographers. They
> have no evidence that SHA-256 is more than marginally better than  
> SHA-1. The
> consensus was that SHA-1 can still be used in the next few years,  
> and that
> when looking for a replacement we have to look beyond SHA-256.
Well, you didn't ask me, and I think I can arrogate my way into that  
set without causing Senate investigations into abuses of power. :-)  
On the other hand, I've been pretty vocal with my opinions, so  
information-theoretically, there would have been no information in  
asking me. Heck, when Russ said, "walk, don't run," he was quoting me.
It matters a lot on who you ask and what you ask them. Let me give an  
example. Last fall at the NIST hash bash, a respected hash designer  
said that if we tripled the number of rounds in SHA-1, we'd all feel  
much better about its security than we do about SHA-256.
I agree with this statement. I think it is a wise and subtle thing  
that says a lot about algorithm design and its challenges. On the  
other hand, it also misses a very important point. I got up and said  
that I agree completely, but --- SHA-1 has 80 bits of security. With  
an infinite number of rounds it will have only 80 bits of security.  
Does this mean that we think that SHA-256 has *less* than 80 bits of  
security? No one said they think that SHA-256 has less than 80 bits  
of security. I went on a limb and said that my guess from licking my  
finger and sticking it in the wind is that SHA-256 has 90-110 bits of  
security. (Today, I feel less good about the 110, but it's still not  
daft.) If you have to pick an algorithm *today*, then SHA-256 is your  
best choice. (Note that I said "best" and not "good." Part of  
understanding the mess we're in is understanding that "best" does not  
mean "good." Donn Parker has a great rant on why we all should stop  
talking about Best Practices.) This is the difference between a  
cryptographer who is an algorithm designer and a cryptographer who is  
an engineer. I'm an engineer. I have to choose something.
Okay, that consensus you described is something that I also agree  
completely with. SHA-1 is okay to use right now, and we need to look  
beyond SHA-256.
I also agree with the statement that you don't have to worry about  
crop failure because next year there will be a new growing season. It  
is a wise an beautiful statement --- and also utterly missing the  
point, if you happen to be caught in the intervening food shortage.
Engineering is the art and discipline of applying science and  
mathematics within constraints. These constraints include time,  
money, effort, and the laws of nature. When we engineers have to  
select a hash function, our non-daft options include SHA-1, SHA-256,  
SHA-512, Whirlpool, and even Tiger. The *best* solution is to  
parameterize the heck out of the protocol; allow SHA-1, encourage  
SHA-256, hope you don't have to go to SHA-512, and put in MAYs for  
Whirlpool, Tiger, and maybe other outré things slipping my mind so  
that we don't have to go to lots of trouble discussing them. And then  
we get on with our lives, and deal with the Godot Hash when it arrives.
There are many obvious tweaks to this strategy. Most of them have  
very good reasons for why you might want to make that tweak. But you  
get my gist.
        Jon


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html