Re: [keyassure] Opening issue #21: "Need to specify which crypto

[Yoav Nir <[e-mail]>]

On Mar 7, 2011, at 4:25 PM, Martin Rex wrote:

>> So SHA2-384 is to be preferred over SHA2-512 because even though it is
>> easier to break, it has a much higher safety factor.
>> 
>> If someone comes up with an attack against SHA2-512 with O(2^480/2)
>> complexity it would reduce the cost of attacking SHA2-512 but not the cost
>> of attacking SHA2-384. So the 512 bit version would be 'compromised' but the
>> 384 version would not.
> 
> That is marketing nonsense.
> 
> With that reasoning, we should use SHA-512/256 rather than SHA-256
> 
>  http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html
>  http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

The point of SHA-512/256 is not marketing or even security, but speed.
http://eprint.iacr.org/2010/548.pdf

> I don't see any value in mandating any algorithm beyond SHA-256
> at this point -- anticipating that there is going to be SHA-3
> in the not so far future and a desire to support SHA-3 in DANE.

I disagree. SHA-512 (and -384) are touted for longevity - we hope that they will be resistant to pre-image and collision attacks for longer than SHA-256. This is important for document signing and somewhat for certificates, but not so much for resource records. If it takes a year from "sha-256 broken" to "exploit in the wild", that's plenty of time to replace all resource records.

So it doesn't make sense to publish SHA-384 resource records now, but we need the consumers of such records to be ready for SHA-384 records. The reason that the transition from MD5 to SHA-1 certificates was so smooth is that all browsers at the time supported SHA-1. 

Yoav