Keccak wins the SHA-3 competition | Hacker News Reader

Keccak wins the SHA-3 competition

csrc.nist.gov

196 pointsB-Con41 comments

Discussion here: http://news.ycombinator.com/item?id=4604188

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.

http://en.wikipedia.org/wiki/You_aint_gonna_need_it

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

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

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

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.

Dear media: It's pronounced 'ketchup'.

No, it's pronounced "ketchak". See http://keccak.noekeon.org/specs_summary.html .

You spoiled the fun.

Kecak is fun, too: http://www.youtube.com/watch?v=0HL5P6wlQPU

It's pronounced "shah three."

I laughed out loud when I read your comment. Very good!

Because that is the chemical formula for ketchup.

Let's say I know a little bit about crypto in general, and wanted to write a software implementation of Keccak/SHA-3 as an academic endeavor. How hard would it be? I'm not looking to produce something that will be certifiably secure against side channel attacks, just something that is reasonably performant and can produce the correct results.

Trivial. See this "Readable C implementation of Keccak": http://www.mjos.fi/dist/readable_keccak.tgz

I find it interesting that the contributors work for semiconductor companies. I would've thought that something like this would be more likely to emerge from a team with a mathematics/CS/academic background more so than hardware. Perhaps these algorithms can (and will) be going strait into some new hardware cryptography IP cores?

I only tangentially follow the semiconductor companies...

However, I know several advanced algorithms in the realm of cryptography can be computationally expensive, and as demand for security grows, several of these semiconductor companies have implemented things in the hardware to optimize certain forms of encryption. (I can't remember if it was Intel or AMD that released a chip with some sort of built-in support for security).

This is just a theory, but if they're going down this road, it would make sense for them to develop a highly secure algorithm that they know can be easily implemented and optimized on the hardware level. If they're developing specialized algorithms AND hardware, they can probably take it into account during the design process and further optimize their boards.

Or, a bunch of semiconductor guys are also crypto-geeks. Which is pretty likely anyway :D.

You were maybe thinking of Intel® vPro™ Technology ?

AES-NI perhaps: http://www.intel.com/content/www/us/en/architecture-and-tech...

All of the SHA-3 candidates were designed to be implementable in fast hardware. Here's a comparison of some of the hardware designs evaluated during the competition:

http://ehash.iaik.tugraz.at/wiki/SHA-3_Hardware_Implementati...

Keccak is one of the most amenable to hardware acceleration, but all of the finalists were good in both hardware and software.

They are all cryptographers and at least three of them have deep academic backgrounds...

Guido Bertoni: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/b/...

Joan Daemen: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/d/...

Gilles Van Assche: http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/a/...

Joan Daemen has a PhD, his thesis was "Cipher and Hash Function Design. Strategies based on linear and differential cryptanalysis"

Gilles Van Assche was a PhD student at the University of Brussels studying "classical and quantum information theory" (http://gva.noekeon.org/)

Just to add another fact here: Daemen is also one of the two co-authors of AES

Why is the Bid/Ask spread so high right now for STMs stock? http://finance.yahoo.com/q?d=t&s=STM

This is normal for low volume stocks during after hours trading.

Is there a free to use and fast implementation of SHA3 in C available ?

No, the standard hasn't been published yet.

Yes, see here for Keccak implementations http://keccak.noekeon.org/files.html

http://keccak.noekeon.org/files.html

The C code appears to be public domain. Which might be a problem in regions in which public domain is not a thing but should otherwise be fine for use in most projects.

It's not the problem, the code is under Creative Commons Zero public domain dedication http://creativecommons.org/publicdomain/zero/1.0/

Wikipedia already has a 3 page description of the Keccak hash approach https://en.wikipedia.org/wiki/Keccak

it's funny, we have new standard, so sha256sum, .., sha512sum utilities should start providing us different results - Keccak, instead of SHA-2 :) i'm wondering how the naming issue is going to be solved

Reply on news.ycombinator.com