But, on the other hand, page
15 of Argon2's specs states that it modifies Blake2b to add 32-bit multiplications in order to increase latency (I guess they mean by needing to wait for extra CPU cycles?).
My questions are:
- If Argon2 wants to make Blake2b harder, why would it reduce its 12 rounds to only 2?
- Are there any other differences that I didn't mention here?
- In which ways do these differences affect the security of Argon2's Blake2b compared to standard Blake2b found in, say,
I think Argon2's use of a hashing function (Blake2b) for filling the memory pad is not the best choice. Because there is no compression involved in filling the memory; 1024 bytes input becomes another 1024 bytes output. No compression happening, hence all the aggressive rounds of a hashing function that tries to preserve maximum input entropy while compressing into much fewer bytes is totally not needed.
I think this is why Argon2 went on to create its own reduced variant of Blake2b with only 2 rounds instead of 12: because it is obvious that hashing is not needed.
Effectively by modifying Blake2b, Argon2 created a variation of a symmetric block cipher, and they went on to use it like one too (fixed input becoming fixed output of equal size).
I think the better approach than Argon2's is, instead of re-inventing a symmetric block cipher off a hashing function (by modifying Blake2b), is to cut the chase and use an existing symmetric cipher like ChaCha20.
Using a symmetric cipher like ChaCha20 will be about as fast as Argon2's re-invented symmetric cipher (reduced Blake2b), even though it is the 20-round ChaCha20. ChaCha20 as per my tests is only very slightly slower than Argon2 for doing the same job. Plus other benefits: taking advantage of existing libraries and more cryptanalysis research that's already went to existing ciphers.