Hacker News new | past | comments | ask | show | jobs | submit login

So, if I'm writing a new application in 2012, should I use SHA-512, or keccak? If course SHA2 will have better library support... What other considerations are there?



You should use SHA2 for now, but be careful no matter what you use.


Given that Bruce Schneier wrote that he'd prefer not having an SHA-3 winner since the SHA-2 algorithms were not showing any weaknesses yet...


That's out of context; Schneier said there isn't one that's significantly better (which he defined as "orders of magnitude") than SHA-2. But they're all strictly better than SHA-2.

If you're writing a new application, by all means use the new standard. If you have an existing application or have to interface with existing frameworks, use SHA-2.


They are strictly better in theory. However, you should keep in mind that SHA-2 is much more battle-tested over the years.


The construction used in SHA-2 is in part inherited from SHA-1, which inherits from MD5, which inherits from MD4. The only hash in that list that doesn't have a scary research finding is SHA-2. There is a general unease about the family of hashes SHA-2 is in (but that doesn't necessitate unease about SHA-2 itself).

SHA-2 also has length-extension, which isn't a hash flaw per se, but is something you have to know about if you're building cryptosystems with the hash (as opposed to using something off-the-rack like HMAC).

If you are using HMAC, you really don't need to worry much about which hash you're using. There is to my knowledge no practical attack against HMAC-MD5.


So you'd prefer they wait until SHA-2 suffers weakness before starting to bring out SHA-3?


You mean like years and years from now? Nice "sky is falling" attitude.



Obvious solution would be to make the application capable of using both. I would default to SHA-512, but I don' see any reason why the hash function should be fixed.


Interesting footnote: because of concerns about the security of both SHA-1 and MD5, the original SSL3 protocol used both MD5 and SHA1 as its PRF. TLS 1.1 changes that with a PRF that relies solely on SHA-2.


Also curious about this. I'm writing something with a DAG storage scheme similar to git, currently using SHA-256 to hash blobs. Been thinking about switching to SHA-512, but there's no rush as I can easily switch hash functions anytime before initial public release. How much time/what indicators can I look for before considering a switch to SHA-3?


For git-like storage schemes speed is important. Keccak is slower than SHA-512, so you probably wouldn't want to switch to it.


For regular hashing it makes no difference

For cryptographic hashing it may make a difference, depending on the context.


In fact, for regular hashing you're probably better off using a non-cryptographic hash in the first place, because they're much faster. Instead of security, they're designed for avalanche behaviour and uniformity of the hash space. Cryptographic hashes also cover these design constraints (otherwise they'd be vulnerable), but a hash does not need to be cryptographic strength to be a really good algo to generate hash keys from blobs.

Murmurhash and Cityhash are two excellent and fast non-crypto hashes. The FNV hash is also quite good, very fast, maybe not as good as Murmer and City, but has the advantage that if you like running your own, it's super-easy to implement (like two lines of C code easy).

FNV hash http://www.isthe.com/chongo/tech/comp/fnv/index.html

Murmur hash http://en.wikipedia.org/wiki/MurmurHash

City hash http://en.wikipedia.org/wiki/CityHash

In case you're interested, here's two great explanations of what to look for in general purpose hashes (avalanche behaviour and uniformity): http://bretm.home.comcast.net/~bretm/hash/ and http://www.partow.net/programming/hashfunctions/index.html


Either, possibly neither. Depends what you want to use that hash for.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: