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

[Martin Rex <[e-mail]>]

Phillip Hallam-Baker wrote:
> 
> We do require TLS however.
> 
> VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the
> choice is thus not 'oddball'.

I assume you rather mean the signature algorithms
sha256WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 11 }
sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 }

rather than the hash algorithms.


> 
> The criteria for abandoning an existing digest is not when the work factor
> below a certain threshold, it is when the work factor falls significantly
> below that advertised.

Nope, I doesn't have anything to do with advertisements.
The problem is when _assumptions_ about an algorithms strength are
shown to not hold, independent of how "strong" that algorithm is
advertised.

This is why we do worry about md5 when used for digital signatures,
and worry much less when md5 is used as HMAC-MD5 for integrity protection
of online communication protocols.



> 
> 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


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.



-Martin