hedging our bets -- in case SHA-256 turns out to be insecure

[james hughes]

On Nov 11, 2009, at 10:03 AM, Sandy Harris wrote:

> On 11/8/09, Zooko Wilcox-O'Hearn <zooko at zooko.com> wrote:
> 
>> Therefore I've been thinking about how to make Tahoe-LAFS robust against
>> the possibility that SHA-256 will turn out to be insecure.
> 
> NIST are dealing with that via the AHS process. Shouldn't you just use
> their results?
> 
>> We could use a different hash function ...
>> There are fourteen candidates left in the SHA-3
>> contest at the moment.  Several of them have conservative designs and good
>> performance, but there is always the risk that they will be found to have
>> catastrophic design flaws or that a great advance in hash function
>> cryptanalysis will suddenly show how to crack them.
> 
> Yes, but there's also a risk that whatever you come up with will turn
> out to be flawed.

I agree.

The logic of a "unknown flaw" being fixed flies in the face of prudent cryptanalysis. If you don't know the flaw, how can do you know you can or have fixed it. 

What if there is an unknown flaw in the fix? Wrap that again? Turtles all the way down. 

Putting multiple insecure algorithms together does guarantee a secure one.

The only solution that works is a new hash algorithm that is secure against this (and all other) vulnerabilities. It may include SHA 256 as a primitive, but a true fix is fundamentally a new hash algorithm. 

This process is being worked on by a large number of smart people. I can guarantee you that this kind of construction has been looked at. 

It is my opinion that putting a bandaid around SHA 256 "just in case" is not cryptanalysis, it's marketing.

Jim

P.S. once Sha-3 comes out, your bandaid will look silly.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com