
Is SHA-3 slow? - snakeanus
http://keccak.noekeon.org/is_sha3_slow.html
======
Asdfbla
My takeaway from this post kind of is that there are probably too many
variants and derivatives of SHA-3. Then again, these days normal developers
should probably use some recommended interface of mature crypto libraries
anyway and shouldn't play around with cryptographic primitives directly, so
maybe more choice for the library devs is good.

~~~
paulddraper
> some recommended interface of mature crypto libraries

Maybe for bubble code it'd be okay to just say "gimma a hash".

But most real code needs to interoperate with stuff. E.g. I need to send a
SHA-256 from a JS client to a Python server. So there needs to be a consistent
and portable "SHA-256" concept that everyone understands.

A cryptographic hash is not a complicated concept (even if developing one is).

I suppose you can think about whether you require collision resistance or
merely second pre-image resistance, but the popular ones are all intended to
be collision resistant anyway.

~~~
mikepurvis
The interop situation with the CRC family of hash functions is terrible. Check
this madness out:

[https://bitbucket.org/martin_scharrer/crccheck/src/default/c...](https://bitbucket.org/martin_scharrer/crccheck/src/default/crccheck/crc.py)

------
lucb1e
Is this "is SHA-3 slow?" or is this "Look our new Keccak-based variant!"?

------
ComputerGuru
Speaking of hashing quickly, I actually just posted an article about hardware-
assisted SHA calculations and their support (or lack thereof) in mainstream
processors, if anyone is interested.

[https://neosmart.net/blog/2017/will-amds-ryzen-finally-
bring...](https://neosmart.net/blog/2017/will-amds-ryzen-finally-bring-sha-
extensions-to-intels-cpus/)

~~~
baby
This was really really interesting! I'm currently trying to get SIMD to work
in Go, and my problem right now is that it's hard to understand which SIMD
instruction I should support (MMX, SSE, SSE2, SSE3, SSE4, AVX, AVX2, ...?) and
how I should test what my architecture supports. If you have any resources on
that I'd take it.

~~~
tjalfi
[0] is a presentation on SIMD targeted at game developers. It has a lot of
valuable information about instruction set support and how to make effective
use of vector instructions. [1] is a HN comment that summarizes the content.

[0]
[https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...](https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf)

[1]
[https://news.ycombinator.com/item?id=9312856](https://news.ycombinator.com/item?id=9312856)

~~~
baby
Interesting, thanks for posting this!

> If you have a 64-bit build, you WILL have SSE2 instructions

Go allows you to detect a few architecture when you build (amd64, arm, arm64,
386) but not really the CPU model. So using SSE2 for anything amd64/arm64
would probably be a good solution.

------
Sami_Lehtinen
There are alternatives like BLAKE2. [https://blake2.net/](https://blake2.net/)

------
kerkeslager
Anyone who thinks that Hacker News comments are a great source of information
should consider the number of top-level commenters on this thread who don't
know the difference between fast collision-resistant hashes and password
hashes, but who decided to post as if they knew what they were talking about.

~~~
dsacco
In fairness, this is because 1) password breaches are the lowest common
denominator of hash function discussions in which developers participate, and
2) developers have it beat into their heads not to use e.g. MD5 for password
storage, but they don't typically receive the same lectures (with the same
vehemence) for things like MACs.

~~~
kerkeslager
I don't really think this is much of an excuse. Fast collision-resistant
hashes and password hashes are _very_ basic crypto concepts. If you don't know
that difference, it would be hard to pass even the most introductory course on
cryptography. If you've literally no education on crypto except what you heard
someone at work say once, you shouldn't feel qualified to correct crypto
articles on Hacker News.

Ignorance isn't the problem. The problem is ignorance combined with
confidence.

~~~
dsacco
I think crypto is a field where one needs an unfortunately low amount of
confidence (relatively speaking) to come across this way, because it's complex
enough that the default position is extreme ignorance. That's why I try to be
a bit more charitable - I don't think people are trying to come across as
authorities on the subject, they just haven't had enough exposure. It's an
unknown unknown. Better crypto education would help.

I've been thinking for some time now about the state of cryptography education
for non-experts, and what I've noticed over the years is we push a lot of
digestible soundbites ("Don't use MD5, don't roll your own, use encrypt-then-
mac", etc) without significant explanations. Sometimes there is an accessible
explanation for these things that's appropriate for a message board comment,
sometimes there isn't, and this advice is necessarily separated from a larger
corpus of material due to the medium.

If telling developers what not to do over and over again in order to dissuade
them from shooting themselves in the foot has made them more secure overall,
this is a good thing. But I do think it comes at the cost of not encouraging
real understanding of why not to do these things. You're right that they
shouldn't take specific positions without that understanding, but I think it
can be hard for them to know they don't have it due to the culture.

~~~
credit_guy
Since you guys appear to be familiar with crypto, can you recommend some
book/article/blog that give a good intro, to the level of explaining the
difference between the two concepts above? Many thanks in advance.

~~~
dsacco
If you'd like to read a book, _Cryptography Engineering_ is probably the best
all around introduction.

If you're looking for an online resource, try Crypto101
([https://raw.githubusercontent.com/crypto101/crypto101.github...](https://raw.githubusercontent.com/crypto101/crypto101.github.io/master/Crypto101.pdf)).

------
sigmar
Summary of the post: SHA-3 is slow, but check out these other recently
proposed parallelized variants of Keccak, they could be much faster.

~~~
espadrine
I read it this way:

\- On hardware, SHA3 is faster than every other contender in the competition.

\- On software, K12 is so fast that the bottleneck will not be its
computation.

------
baby
There is an RFC being drafted on K12 here: [https://tools.ietf.org/html/draft-
viguier-kangarootwelve-00](https://tools.ietf.org/html/draft-viguier-
kangarootwelve-00)

~~~
tptacek
Why would this matter? You can get an IETF RFC drafted on pretty much
everything. Dan Harkins even got Dragonfly an RFC:
[https://tools.ietf.org/html/rfc7664](https://tools.ietf.org/html/rfc7664).

~~~
baby
I'm just pointing out this thing because it's relevant and was released two
days ago :)

------
annnnd
Genuinly curious: isn't the whole point of cryptographic hash functions that
they are slow by design, so that they _can 't_ be made faster?

~~~
bonzini
No, you're confusing them with password hashing functions (bcrypt, scrypt) and
password-based key derivation functions (PBKDF1, PBKDF2). These _are_
cryptographic hash functions, but they are designed to iterate many many times
(the exact number is customizable) in order to take a given amount of time.

"Generic" cryptographic hash functions like SHA-1/SHA-2/SHA-3 (or BLAKE, or
MD5) don't iterate more times than is necessary for security, and are designed
to be as fast as possible. This way, you can hash multi-gigabyte documents in
a fraction of a second.

~~~
annnnd
Thank you for the clarification!

------
almostdigital
Who's gonna be the first to launch KangarooCoin or KeccakCoin with a SHA-3
proof-of-work?

~~~
baby
There are already a bunch of blockchain stuff using SHA-3 apparently. If
people want to drop a list of products/companies/apps that use SHA-3 (or other
Keccak construction) I'd be interested!

Ethereum uses SHA-3 to begin with.

~~~
Kubuxu
To be precise it uses variant of Keccak as NIST changed parameters of SHA-3
when they were already using it.

~~~
baby
They started using SHA-3 before it was standardized?

------
Tenoke
A bit off-topic, but I am currently trying to recover ~$70000 worth of
ether[1] from my presale wallet and the encryption used is indeed SHA-3.

I'm currently trying 21970881 passwords against the hash using fairly basic
python code (ETA: 2-3 days), and can definitely use tips for speeding up the
work, as Id likely need to try an order of magnitude or 2 more generated
password in order to crack it.

1\.
[https://etherchain.org/account/0x35f5860149e4bbc04b8ac5b272b...](https://etherchain.org/account/0x35f5860149e4bbc04b8ac5b272be55ad1aca58e0)

~~~
esnard
You should definitively use hashcat[0]. It's the fastest hashing tool at the
moment, and it supports both PBKDF2-HMAC-SHA256 and SCRYPT for Ethereum
wallets since the last update.

It can test 588 passwords per second on my modest GPU. I guess that's a lot
better than a basic Python script.

You should also have a look at probable wordlists[1], which contains a lot of
passwords sorted by their popularity. It could significantly speedup the
research, as long as your password has already leaked elsewhere.

[0] [https://hashcat.net/hashcat/](https://hashcat.net/hashcat/)

[1] [https://github.com/berzerk0/Probable-
Wordlists](https://github.com/berzerk0/Probable-Wordlists)

~~~
Tenoke
The password definitely hasn't leaked as it is a one time password I created
based on a somewhat complex scheme, but switching to hashcat (as also pointed
outby flipp3r) seems to be the best next step.

------
atemerev
Slow security is good security.

It makes brute forcing more difficult, and promotes decentralization of
infrastructure (slowness adds up only for large-scale deployments like Google
and Facebook, and we want to depend less on centralized actors, not more).

If you need to choose between strength and performance, choose strength in
nearly 100% of all cases. You make the job of NSA or GRU much harder, and
promote offsetting security mechanisms to the edge, where they ought to be.

~~~
kerkeslager
> Slow security is good security.

This is simply not correct. There are a few cryptographic problems where
slowness is the solution, but in most cases you want your cryptographic
algorithms to be fast.

~~~
atemerev
Could you please counter my arguments (brute force security against
immeasurably larger computing power, resilience to novel unknown crypto
attacks reducing the algorithm strength) with something more substantial than
"this is simply not correct"?

~~~
kerkeslager
I could, but doing so would likely involve teaching you a good chunk of crypto
101 while you try to tell me I'm actually wrong so you can be right, which
would be enjoyable for neither of us. It would be more efficient for you to
just take a introductory course on cryptography from someone more qualified
than me. I'm not trying to be rude here, it's just clear that you've learned
about password hashing and then assumed based on that one exceptional case
that slowness is how all of crypto works. It's not, and you shouldn't make
claims about all of crypto if the only thing you know about crypto is that
password hashing works by being slow.

------
mtgx
I think it's crazy that we're considering "settling" for a 128-bit hash
function that we won't even start to adopt until 5-10 years from now, when
Google is already planning to announce its 49-qubit quantum computer by the
end of this year. It's also very likely that quantum computers will scale at a
"Moore's Law" of sorts rate (doubling the qubits every 2 years or so, if not
even faster in the first few years). We've seen that with D-Wave already.

[http://spectrum.ieee.org/computing/hardware/google-plans-
to-...](http://spectrum.ieee.org/computing/hardware/google-plans-to-
demonstrate-the-supremacy-of-quantum-computing)

I feel the same about all of those "faster" (read: weaker) IoT-optimized
crypto algorithms that are being proposed right now for standardization.

What we should be talking about now is quantum-resistant algorithms that are
likely to be even _slower_ than SHA-3, but would at least protect
communications against quantum computers. We need them soon, because they'll
have to be deployed on 80%+ of the internet by 2030 or so, and we know how
slow the internet ecosystem is at adopting a new protocol.

~~~
snakeanus
> I think it's crazy that we're considering "settling" for a 128-bit hash
> function

Actually the sponge capacity in the so called 128-bit keccak functions is 256,
they only call them 128-bit because they provide 128bits of preimage and
collision resistance (at 256 bits of output). In a quantum setting the
difficulty for preimage and collision attacks for these functions is
2^(256/3), when assuming that the output is of at least 256 bits.

> What we should be talking about now is quantum-resistant algorithms that are
> likely to be even slower than SHA-3

SHA3-256 has c = 512 and output of 256 bits (128 bits of preimage resistance
and ~85 bits of collision resistance on a quantum setting), while SHA3-512 has
c = 1024 and output of 512 bits (256 bits of preimage resistance and ~170 bits
of collision resistance on a quantum setting). I would say that both of the
above sha3 versions are quantum resistant.

Most modern symmetric cryptography would safe in a post-quantum world, I would
say that the only thing that is left is to adopt post-quantum asymmetric
algorithms more widely.

~~~
baby
> they only call them 128-bit because they provide 128bits of preimage and
> collision resistance (at 256 bits of output).

You're right, Appendix A.1 of
[http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf](http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf)

------
codazoda
I'm not sure if SHA-3 has a design goal of being fast. My understanding is
that, if your using it for encryption, for example password storage, you want
it to be slow. This helps with brute force attacks, particularly if someone
gets ahold of your database full of password hashes and can unleash as many
calculations as they want. Because the SHA family has typically been fast,
they are considered bad candidates for passwords. My quick Google foo doesn't
turn up the goals of the competition, but I'm guessing being fast might be a
negative.

~~~
willvarfar
SHA-3 is supposed to be fast.

Do not use SHA-3 for password storage!

Use a key-stretching password hash function e.g. bcrypt or scrypt.

(These take a fast hash or encryption function and apply it many many times,
to make the total work be slow.)

~~~
dragontamer
You're technically wrong, but your concept is right. BCrypt and SCrypt are
originally designed to be slow.

PBKDF2 is the function that takes a fast hash function and applies it many
times to make it slow.

