Ben Laurie blathering

What Is SHA-3 Good For?

Cryptographers are excited because NIST have announced the selection of SHA-3. There are various reasons to like SHA-3, perhaps most importantly because it uses a different design from its predecessors, so attacks that work against them are unlikely to work against it.

But if I were paranoid, there’d be something else I’d be thinking about: SHA-3 is particularly fast in hardware. So what’s bad about that? Well, in practice, on most platforms, this is not actually particularly useful: it is quite expensive to get data out of your CPU and into special-purpose hardware – so expensive that hardware offload of hashing is completely unheard of. In fact, even more expensive crypto is hardly worth offloading, which is why specialist crypto hardware manufacturers tend to concentrate on the lucrative HSM market, rather than on accelerators, these days.

So, who benefits from high speed hardware? In practice, it mostly seems to be attackers – for example, if I want to crack a large number of hashed passwords, then it is useful to build special hardware to do so.

It is notable, at least to the paranoid, that the other recent crypto competition by NIST, AES, was also hardware friendly – but again, in a way useful mostly to attackers. In particular, AES is very fast to key – this is a property that is almost completely useless for defence, but, once more, great if you have some encrypted stuff that you are hoping to crack.

The question is, who stands to benefit from this? Well, there is a certain agency who are building a giant data centre who might just like us all to be using crypto that’s easy to attack if you have sufficient resource, and who have a history of working with NIST.

Just sayin’.


  1. Well, it was designed by people at ST Micro and NXP who have many legitimate reasons for wanting it to be fast in hardware (TPMs, smart cards, etc.) Fast in hardware also means lower power, which is useful for RFID tags/contactless smart cards that want to HMAC their communication.

    Comment by Karl Koscher — 4 Oct 2012 @ 10:54

  2. Sounds like you have a poor grasp of the point of this type of hash

    Comment by Ben — 4 Oct 2012 @ 17:18

  3. I should clarify that the Ben in #2 is not this Ben. But now I’m wondering who he was addressing…

    Comment by Ben — 4 Oct 2012 @ 21:27

  4. Ah, but which Ben is the real “Ben Laurie blathering”?

    Sounds to me like we all have a poor grasp of message sender identity.

    Comment by Marsh Ray — 4 Oct 2012 @ 21:34

  5. If you’re still wondering about attacker’s advantage of Keccak for passwords, check out fig 6 and figs 4.2 and 4.4.

    Comment by Marsh Ray — 4 Oct 2012 @ 22:21

  6. Don’t use SHA* for hashing passwords, use something like bcrypt.

    Comment by Kyhwana — 4 Oct 2012 @ 22:35

  7. Uhm just to clear things up: hash functions like MD5 or SHA- are not actually supposed to be used for storing passwords. They’re designed to be as fast as possible while still having a low risk of collisions and a high minimum distance for small differences in inputs.
    And that is exactly not what people want when it comes to storing passwords, those functions should be wastly slower.

    There are a variety of password storage functions, for example bcrypt or PBKDF2- (which is actually a key derivation algorithm, but that’s nearly the same thing anyway – same goals, similiar usage).

    Comment by mabe — 5 Oct 2012 @ 13:57

  8. So it is fast in hardware. Why is that a benefit for attackers if the key size can be 1600 bits? If their machines are 2^1000 times faster than mine it’ll still take forever to process those bits brute-force.

    Comment by Bob — 5 Oct 2012 @ 14:23

  9. I think you should rethink your blog post. I mean:

    “It is notable, at least to the paranoid, that the other recent crypto competition by NIST, AES, was also hardware friendly – but again, in a way useful mostly to attackers.”

    Is not a bright statement the i5 and i7 processors have Hardware support for AES and they have been the most sold processors of the last year. Some people encrypt Network traffic with 1 GBit without Hardware support that is not possible others encrypt whole Harddrives. Do you know what you are talking about.

    Comment by Carsten — 5 Oct 2012 @ 14:41

  10. AES hardware accelleration is now available in general purpose processors (AES-NI instructions on x86, also in ARMv8), so yes, finally we all get some benefit of the “fast in hardware” thing. A Keccak primitive in hardware is also quite useful, as it is a general purpose primitive, so you can do everything: en/decryption, MAC, hash, PRNG, with an approach that is significantly more advanced than AES.

    The more paranoid view of this is of course that NIST will nominate a winner, when the team disclosed a backdoor to NSA. A backdoor that still requires significant hardware to be used, because this option shouldn’t be available for “the enemy”.

    Comment by Bernd Paysan — 5 Oct 2012 @ 14:49

  11. Yes, as the technical background is a matter of fact (not a scenario), and why shouldn’t a government “try sth.” (constantly, for any ugly reason one can imagine)? Scrupulosity? Haha. Nowadays, with history in mind, I agree, it’s not too paranoid to be a litte paranoid; by reasoning.

    Comment by meta — 5 Oct 2012 @ 15:18

  12. What’s so bad about fast in hardware? Isn’t it the expectation for any security/cryptographiy consideration, that there will be attackers with access to very fast hardware? Isn’t then making an algorithm particularly hard to implement in hardware just a security by obscurity thing? I thought it being secure despite fast hardware was the whole trick to this thing.

    I’m no cryptography expert, far from it. Just a normal guy who likes his privacy. With AES in hardware (AES-NI in modern cpus) I started to encrypt everything regardless of necessity. Which simply wasn’t possible before because of performance reasons. AES without hardware is simply way, way too slow to use everyhwere.

    So for me, it’s either AES or nothing. I think I prefer AES…

    Comment by Quadrulomaniac — 5 Oct 2012 @ 15:26

  13. I’ve always wondered about this whenever a new algorithm was presented, maybe because I’m not a crypto-expert at all. But why would the average Joe with his average apppliance benefit from hardware friendly hash algorithms? It’s not like his computers do nothing but hashing. Besides the fact that there are no special purpose circuits built in most CPUs even today anyway, since they are not needed really, because, well, the average Joe’s computer does not do nothing but hashing all day long.

    There are special appliances however for businesses that would benefit from it. And it’s chip manufacturers like STMicro and NCP and others who would then cash in with special built processors. You can at least say that NIST may be industry friendly, that they purposely recommend a hash algorithm with an “unfortunately” shorter life expectancy in order to favor their industry partners who want to sell this algorithm in the form of effeciently hardcoded special purpose chips. According to Occam’s Razor this makes much more sense to be NIST’s intention. They don’t favor a fast-in-hardware design because it’s easier to crack, but because it’s more profitable to sell it as a chip. There’s no money for the vast majority of NIST’s industry partners in stealing passwords… but it would also make sense for the NSA to support such an organisation like NIST with such a consumer-unfriendly and weak agenda.

    Comment by Ben #3 — 5 Oct 2012 @ 17:09

  14. If i recall correctly the blake and skein were faster

    Comment by random_internet_guy — 6 Oct 2012 @ 8:56

  15. The author might be right, but is there still a problem if one uses a
    $cat /dev/urandom | tr -cd ‘[:graph:]’ | head -c 12
    like password with 12 characters?:
    95^12keys/(10000000*1000000)keys/second[1] = 5.4*10^14 seconds = still 1756.78 years.

    [1] Fast PC, Dual Processor PC. 10000000 Passwords/sec, times 1000000 of them.

    Comment by random guest — 6 Oct 2012 @ 15:11

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress