Argon2 with SHA-256 instead of Blake2

Question

Can SHA-256 be substituted for Blake2 in the Argon2 algorithm?

I am working my way through the C reference source code for Argon2 and hand-translating it to Go. I was just wondering why Blake2 was chosen instead a well-tested algorithm like SHA-256.

Answer 1

1. If you take a look at the Password Hashing Competiton, you can see, that most of the schemes use Blake2b, some of them uses SHA-512, none of them uses SHA-256.

   Blake2b is optimized for 64-bit platforms and this property fits exactly the requirement of a password hashing scheme. SHA-512 would also be OK, but SHA-256 would be much slower in software and the due to the fact, that SHA-256 is used for Bitcoin mining, custom hardware for SHA-256 is very cheap – this is exactly, what we do not want for a password hashing scheme.

   I do not recommand to substitute any part of Argon2. All cryptoanalysis refer to the original version. Argon2 is – unlike Catena (another scheme from the password hashing competition) – not a flexible framework, that has been designed to be used with variable algorithms.

2. Argon2 uses not only the Blake2b function, but also something like a reduced version of Blake2b, the compression function G. You could possibly replace Blake2b by SHA-256, but you can‘t replace easily the reduced version, because Blake2b uses fewer rounds than SHA-256.

Answer 2

From reading the Argon2 paper, it would be safe, but not wise, to use SHA-256 instead of Blake2:

We allow to choose another compression function G, hash function H, block size b, and number of slices ℓ. However, we do not provide this flexibility in a reference implementation as we guess that the vast majority of the users would prefer as few parameters as possible.

Blake2b is used in two different places in Argon2. The first is as a generic cryptographic hash function to combine the password and other parameters. The second is as the compression function which does the bulk of the work. The compression function doesn't actually require the same level of cryptographic security as a hash might, so it uses only two Blake2b rounds instead of twelve. The rounds are also slightly modified, where modular additions are combined with modular multiplications in order to decrease ASIC performance^*. This construction, taken from Lyra2, was named BlaMka.

While SHA-256 could be used for both of these purposes (with adjusted block sizes), it would not improve security. While it would not necessarily decrease security, it would increase the relative advantage of the attacker. This is because Argon2's compression function is heavily optimized in order to minimize the amount of cycles taken while still providing adequate diffusion. SHA-256 requires far more cycles than BlaMka for the same amount of output, which decreases the memory fill rate and gives the attacker an advantage. See section 6.3 for more information about the design criteria that went into the compression function and, in particular, how vital it is to maximize cycles per byte.

In conclusion, using SHA-256 instead of Blake2b and BlaMka would not decrease the cryptographic security of Argon2, but it would give an advantage to the attacker by requiring the defender's computer to perform computations that slow it down without slowing the attacker down to the same extent.

_{*DJB's Salsa20, which Blake2 is indirectly based on, did not use modular multiplication only in order to allow for timing attack resistance. The way Blake2 rounds are used in Argon2's compression function is such that timing attacks are not an issue, making it possible to use modular multiplication safely.}