
Maybe we shouldn't skip SHA-3 - baby
https://www.cryptologie.net/article/400/maybe-dont-skip-sha-3/
======
tptacek
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.)

~~~
JoachimS
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?

~~~
taneq
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.

~~~
wybiral
I think the point they were making was that since we know of weaknesses in
certain situations we should avoid using it even in the safe situations so
that we can eventually drop it from crypto libraries all together. There are
alternatives that we can all move to.

~~~
yakult
So what's the right algorithm to use instead of md5 if I just want a fast
checksum that's widely supported?

~~~
svenfaw
SHA256

~~~
dom0
If SHA-2, do use SHA-512, since we are living in a 64 bit world.

~~~
JoachimS
SHA-512/256

------
nilved
> 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](https://en.wikipedia.org/wiki/Dual_EC_DRBG)

~~~
smitherfield
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.

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

~~~
smitherfield
Fair enough, although I'd still say it is; hashes that've received the NIST's
imprimatur have all been above-average compared to their contemporaries, and
none of them appear to have any intentional weaknesses.

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

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

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

------
remcob
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 :)

~~~
baby
> 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
In hash function competitions, are the authors of the function allowed to vote
for their own entry?

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

