Maybe we shouldn't skip SHA-3

https://www.cryptologie.net/article/400/maybe-dont-skip-sha-3/

by baby • 9 years ago

106 110 9 years ago

tptacek17• 9 years ago

If you're going to pick a hash specifically to avoid length-extension attacks, pick SHA-2 512/256, which isn't vulnerable to length extension attacks. Or, for that matter, pick Blake2, which is a slightly less idiosyncratic choice than SHA-3. Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance.

SHA-2 512/256 is much faster than SHA-3 and supported by more libraries.

The notion that by recommending SHA-2 512/256 you're setting people up to use prefix MAC SHA-2 512 or SHA-2 256 is kind of silly. You could similarly argue that by telling people to use SHA-3, you're risking that they "fall back" to SHA-2. Either way, you're calling for a specific hash.

The reality is that some people like SHA-3 because it's interesting and because its primitives can be used for a variety of non-hashing applications. That's true! Nobody is saying SHA-3 shouldn't exist. They're just saying: there's no good reason to use it in a modern application.

(If you're not clear on length-extension attacks: they're the reason we use HMAC. HMAC-SHA2 isn't vulnerable to length extension attacks; neither is HMAC-SHA1 or HMAC-MD5 --- both of which, fun fact, can't currently be attacked, despite the weakness of their underlying hash. But if you use SHA-2 512/256, you don't have to use HMAC.)

JoshTriplett• 9 years ago

Everyone --- including the authors of SHA-3 --- is unhappy with the SHA-3 parameters and resulting performance.

Would another variant of Keccak, not the one that became SHA-3, provide more competitive results? Or does Keccak in general not have compelling properties compared to the alternatives?

tptacek17• 9 years ago

Yes, there is one: KangarooTwelve, by the Keccak authors.

The problem is, there's just not a lot of reasons to use it. SHA-2 isn't broken; in fact, there are hash cryptographers who think SHA-2 may never be broken.

aseipp• 9 years ago

The parameters NIST specified are just fairly conservative, for one thing (e.g. NIST, IIRC, oddly requested an increase in the number of rounds during the final stages, one of the things people waxed on about.)

Regarding another variant: yes, you can get more compelling results, and the authors of Keccak themselves have also proposed another function based on Keccak called KangarooTwelve[1]. K12 has much better performance and parallelism than SHA-3 does in software. (Of course, if you don't need most of Keccak's general properties, you're probably fine with other hashes anyway.)

[1] http://keccak.noekeon.org/KangarooTwelve.pdf

cryptonector4• 9 years ago

SHAKE is Keccack with parameters that are comparable to SHA-2's, and so performs better.

baby11• 9 years ago

I think our comments and discussions just add to the general confusion though, this is why I just plainly recommend SHA-3.

Now if I would personally work on a project I would think of SHAKE first, and I would seriously consider KangarooTwelve (especially for tree hashing, which makes K12 better than any other hash to hash big files).

tptacek17• 9 years ago

You keep saying that here, and on Twitter, and people --- not just me --- keep telling you that if you're going to recommend a hash specifically to avoid length extension attacks, 512/256 accomplishes that without requiring the adoption of new hashing code.

I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256? We could call it SHA2.5: better than SHA-2, not quite SHA-3. Or SHA5: better than both!

Renaming SHA-2 512/256 sounds a lot easier than getting new hash code implemented in every library.

snakeanus3• 9 years ago

(especially for tree hashing, which makes K12 better than any other hash to hash big files).

I am aware that other modern hash functions like BLAKE2 (and maybe BLAKE/Skein?) support tree hashing, is there any reason why K12 would be better for that?

JoachimS7• 9 years ago

Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use.

Do you agreee with that advice?

baby11• 9 years ago

Yeah, that's a good argument to move to a stronger hash function for HMAC.

tptacek17• 9 years ago

Definitely don't use MD5!

taneq• 9 years ago

It depends what you're using it for, no?

If you're using it as part of an auth mechanism then sure, don't use it. If you're using it for anything else (checksum, verification etc.) where you don't expect any adversarial action then it's fine.

oconnor663• 9 years ago

BLAKE2 is faster than MD5. I think that means there's no longer any reason to use MD5 in new applications, if you have any choice.

cryptonector4• 9 years ago

Yes-ish. I don't sweat HMAC-MD5, nor HMAC-SHA-1. What really sucks though is when you can't use them (even though for interop reasons you must) because some stupid auditor (typically software) goes "oh no! MD5 found!! alert! alert!".

kobeya2• 9 years ago

How is SHA-512/256 not vulnerable to length extension attacks? I've implemented the SHA family of hash functions before and the only real difference between the two is block size and truncation of output, but I don't see how that stops length extensions.

helper• 9 years ago

You can't add more data once you've truncated.

nialo• 9 years ago

Have you tried implementing the length extension attacks?

Truncating from 512 bits to 256 bits hides 256 bits of the state from the attacker, so in order to use a length extension attack they would need to "guess" those bits.

dom09• 9 years ago

SHA-512/256 is a variant of SHA-512 where the output is truncated to 256 bits. It does not mean "SHA-512 or SHA-256". Yes, perhaps a different symbol than "/" would be better there.....

jfindley• 9 years ago

To be fair, while I do agree with you, sha-2 512/256 is an especially confusingly named hash. A _lot_ of people naturally read it as sha-2 512 or 256, which it is not, but thing/otherthing is a common enough pattern that the confusion is understandable.

sha-2 256t or something would be much clearer. As the article notes, changing it now is not trivial, but given the potential for confusion is something that might be worth doing, none the less.

dom09• 9 years ago

I've seen it written as "SHA-2 512-256", which is a bit less confusing.

nilved2• 9 years ago

The reality is that you should use SHA-3. I'm making this as a broad recommendation for people who do not know much about cryptography. You can't go wrong with the NIST's standard.

https://en.wikipedia.org/wiki/Dual_EC_DRBG

smitherfield3• 9 years ago

If your claim is that SHA-3 contains an NSA backdoor, that's an extraordinary claim requiring extraordinary evidence.[1] In the case you link to, the NSA was publicly the author and the backdoor was "obvious" nearly from the start.

[1] Or else a conspiracy theory. Not that conspiracy theories are never true; I'd be surprised but not shocked if this one were.

nilved2• 9 years ago

No, my claim is simply that NIST sponsorship is not a good reason to use it.

JoachimS7• 9 years ago

It wasn't obvious enough to prevent it from slipping into being not only a NIST standard, but also standards by ANSI and ISO. Quite a lot of people around the world that accepted it.

baby11• 9 years ago

Oh yeah I should rephrase that :D

johnhenry• 9 years ago

We can look at technologies from two different points of view -- a engineers or as scientists. As engineers, we look at sha-3 as a practical means to an end -- just a secure hashing algorithm. From that point of view, its un-necessary as we already have sha-2. As scientists, it's an experiment and we're still waiting to see the results. The hypothesis is that its existence will strengthen our existing pool of hashing algorithms. We should note that this is a poor hypothesis; given that we don't see any flaws in our [only?] other algorithm, it's currently impossible to test. However; as with many other important experiments, we are seeing other un-expected results and applications. As an engineer, I acknowledge that it's probably best to skip it in most production applications. But as a scientist, let's not skip if anything cool happens down the line?

cryptonector4• 9 years ago

So, AGL was speaking specifically about TLS. He wasn't suggesting other protocols / formats not use SHA-3 / SHAKE. But this blog post talks about misuse of hash functions as a reason to switch to SHA-3 as if AGL had not referred only to TLS.

That's a strawman. It's NOT useful.

EDIT: What's the one downvote for? Just curious!

tytso• 9 years ago

I think the argument that people could misuse SHA-2 is bogus, because if people are rolling their own crypto, they can get themselves into a lot of trouble, not just with SHA-2(key || data). Indeed, that argument may cause people to assume that it's ok for application programmers to do cryptographic protocol engineering, which would be disastrous.

A much more general argument is that most people should be using cryptographic frameworks (e.g., which implement TLS), and Adam Langley's thoughts about whether or not SHA-2 should be skipped should be aimed at people who are creating those cryptographic frameworks.

But if we are giving advice to random application programmers, they shouldn't be trying to pick cryptographic algorithms to begin with, and the question of whether you should be using SHA-2(key || data) is the sort of thing where the Zen master would be hitting the student with a cluestick for asking the wrong question to begin with.

remcob• 9 years ago

In which use cases is the asymptotic cycles per byte relevant compared to the small case performance?

I mostly use hashes as part of signing/verifying small messages, say an 80 byte JWT, a Blockchain transaction, a certificate, an TLS/SSH packet, etc. Besides hashing large files (which I rarely do), I don't see where I would reach asymptotic performance, or even use tree-hashing.

SHA3's block size is 200 bytes, KangarooTwelve's is, if I'm not mistaken, 8192? I'm more worried about not even filling the first block :)

baby11• 9 years ago

I mostly use hashes as part of signing/verifying small messages, say an 80 byte JWT, a Blockchain transaction, a certificate, an TLS/SSH packet, etc. Besides hashing large files (which I rarely do), I don't see where I would reach asymptotic performance, or even use tree-hashing.

The number I used is definitely not the best one. But I believe it applies to you as you're not hashing a lot of bytes so you will not see much of a speed difference between hash functions.

SHA3's block size is 200 bytes, KangarooTwelve's is, if I'm not mistaken, 8192? I'm more worried about not even filling the first block :)

They have the same block size :o rather 8192 is the threshold before you start using the tree hashing mode. This way if you want to hash small messages you do not get a penalty from using KangarooTwelve! It's all good :)

super-io• 9 years ago

In hash function competitions, are the authors of the function allowed to vote for their own entry?

niftich• 9 years ago

It's unfortunate that the 'bar' in misuse-resistant crypto isn't always equally high, and different experts (as evidenced from this thread) argue that you get there in different ways. In that regard, I think the author makes a good point: despite the hard-to-implement-in-hardware aspect of GCM, the dangers of nonce reuse have always been well-documented, and it's only recently that that went from being a simple algorithmic contract to bad design worthy of correction.

I think the point the OP makes is that a suggestion like "use SHA-3" is a simple, succinct, and not-unacceptable answer to a question like "what cryptographic hash function should I use?", giving a safe albeit conservative, but instantly graspable answer without having to go into additional detail -- other than the obligatory mention to that general-purpose hash functions aren't by themselves appropriate for key derivation ("password hashing").

The alternative view -- that SHA-512/256 (which suffers from its naming), or the longer-but-less-truncated-state SHA-384 is faster, more studied, more widely supported -- is a more nuanced recommendation, but then you have to explain why you don't mean SHA-256 or SHA-512. The innovation of libraries like nacl and libsodium was to the user of crypto from having to be a crypto expert themselves, and once you have to explain which of the SHA-2 hashes specified in FIPS PUB 180-4 you should and shouldn't use, we're not really any better than in the footgun days.

Maybe we shouldn't skip SHA-3

Related Stories