*** Markus Wichmann [2021-04-14 06:03]:
>I don't care about the speed of a hash function.
If we a talking here about checking software integrity, then speed is
important. Millions of people check the hash of downloaded files -- if
it is slow, then huge quantity of time/energy is wasted. Less time you
spent on hashing, less energy is wasted. SHA2 (and SHA3 too, if we are
not talking about KangarooTwelve modifications) is the worst choice from
ecology point of view.
>I think bitcoin mining is pollution
I agreed. But I see nothing in common between proof-of-works and hash
functions. PoWs ("good one", like Argon2 that can be used for that task)
uses special construction -- it does not matter if underlying hash is
fast or slow, because we can simply make more iterations with it.
>and in case of password cracking, having a slower hash
>function is an advantage for me
That can only mean that you still use an ancient PBKDF2-like schemes of
password strengthening. A long time ago a Password Hashing Competition
brought us memory-hardened hashing functions like Argon2 (winner), and
Balloon (appeared after PHC, but my favourite). Hash function speed do
not play any considerable role there, because memory is actively used
and *is* the bottleneck for brute forcing operation. Anyway, slower hash
for PBKDF2 means that number of iterations will be smaller -- faster
hash means more number of iterations. So only the dead simple password
hashing constructions like hash(password) will benefit from slower hash,
that is just silly and unacceptable to use at all, if you worry about
brute-force cracking.
>I am not a cryptographer. From what I understand about SHA-3, it offers
>a better HMAC function
1) Do not confuse "MAC" and "HMAC". HMAC is a special construction
(H(K XOR opad) || H((K XOR ipad) || m)) that can make a MAC with hash
functions. It is required at least because many hash functions are
constructed as Merkle–Damgård, that has some properties preventing
simple H(K || m) usage.
2) SHA3 is not Merkle–Damgård and can be safely used as a MAC with just
H(K || m) calculation. HMAC can be used with SHA3 without any problems,
but it just calls hash function one more time. For big messages that
does not play any noticeable role at all (hashing of terabyte and one
more hash of dozens of bytes), but for small one "native" SHA3-MAC just
will be faster.
3) "Native" SHA3-MAC is not better. It is just the same, from security
point of view. Nothing wrong with HMAC, nothing wrong with SHA3-MAC.
Latter will be just faster especially for small messages.
>(the whole padding thing is not needed anymore,
>since hash extension attacks are not possible).
Yes, HMAC prevents them. SHA3 is simply immune for them out of box,
because of its sponge construction. Nothing is wrong with both of them,
noone is better.
>Cryptographers had a big old competition over the
>"best" hashing algorithm and in 2012, Keccak won.
There are too many questions what is "best". Keccak won mainly because
it is not Merkle-Damgård construction that ****probably**** someday can
be found to be problematic with more issues. ****Possibly**** that
construction itself was a mistake. SHA3 is a ready replacement **if**
something is wrong with SHA2. Official statements require to replace MD5
and SHA1 with SHA2+. But there are no statements and recommendation to
replace SHA2 with SHA3, because nothing is wrong with SHA2.
>And I will continue to advocate for its use exclusively over SHA-2 to
>keep the zoo of hash functions small. SHA-3 should be used for its HMAC
>property alone, and it is adequate for all other tasks, so there is also
>no reason to keep SHA-2 around.
Nothing wrong to use SHA3. But it is wrong to say that SHA2 is somehow
bad and must be replaced. That is why even newer creations, knowing that
SHA3 is already here for a long time, still choosing SHA2 exactly for
keeping the zoo of hash functions small, because noone is going to
replace already existing SHA2-driven software with SHA3. Why Git is not
moving to SHA3 from SHA1? Because there is no point in that, nothing is
wrong with SHA2 existing in every piece of libraries.
But anyway there is no possibility just to stay with only SHA2 or only
SHA3. Because all of them are slow. I use hash alone for verifying data
integrity and I need for speed. That is why BLAKE2/Skein are so
popular and BLAKE3 is gaining popularity too. And as I remember, Skein
even has security marging higher than Keccak. BLAKE2 has completely
acceptable margin for all cryptographic tasks too. Possibly KangarooTwelve
will gain popularity too. But zoo will always be with us.
And do not overestimate importance of having MAC function alone.
Currently all protocols are moving to AEAD-based ciphersuites (TLS1.3
and Noise work only with AEAD ones), where MAC is not used alone anymore.
CCM and EAX AEAD modes uses only the cipher function, GCM uses GHASH
(not a hash, not a cipher), ChaCha20-Poly1305 uses Poly1305 which is
special onetime MAC function, but none of them use anything related to
hash functions or HMACs. Of course there are hundreds of places with
MAC-alone-usage exists, but not as dozens years ago where it applied to
every IPsec/TLS/whatever packet to authenticate it.
And if you protocol assumes that various hashes can be used with it
(Merkle-Damgård-based or anything else), then you are forced to use
and rememeber about HMAC. You can tell to use SHA3 directly, if SHA3 is
used as a hash, but it is complication. That is why modern TLS1.3 or
Noise still use HMAC, even if SHA3 is used with them. There was
discussion about that in Noise mailllist, because even BLAKE2 offers the
same ability to use it as a MAC directly, Skein too (all of them are
widely used), but decisions is to leave HMAC anyway, for protocol
simplification. So it is hard to see where native-SHA3-MAC can be used
in practice in protocols without hard-coded algorithms. Nothing wrong
with HMAC-SHA3, except for one more small message hashing at the end,
that is negligible and won't be used for transport traffic because of
AEAD ciphers.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Received on Wed Apr 14 2021 - 08:05:01 CEST