On Wed, Apr 14, 2021 at 09:05:01AM +0300, Sergey Matveev wrote:
> *** 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.
>
Generating hashes for all dl.suckless tarball files (287 files) takes 0.75
seconds in total, it is not an issue.
What is the preferred hash by Greta?
> >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
>
--
Kind regards,
Hiltjo
