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.

  • 1
    $\begingroup$ Assuming the parameters fit (I didn't check), yes you can substitute Blake2 with SHA256, but of course it won't be Argon2 anymore. $\endgroup$
    – SEJPM
    Nov 18, 2017 at 15:58

2 Answers 2

  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.

  • 1
    $\begingroup$ Minor comment: developing a hardware implementation for most hash algorithms isn't a major obstacle. Bitcoin miners are ASICs, however, and are typically unable to do anything but brute force that one specific nonce word within the double-sha256 bitcoin uses, all in the name of saving a few percent of power. There is that custom hardware in common SoCs and CPUs to consider, though. $\endgroup$ Nov 18, 2017 at 21:19
  • 1
    $\begingroup$ @YannVernier that is why Blake was chosen, because it is very fast on a general purpose CPU, and would not see as large a speedup with custom hardware $\endgroup$ Nov 19, 2017 at 8:29
  • $\begingroup$ @RichieFrame Exactly, the point of good password hashing algorithm is to be cheapest to run on server class CPUs. If you set the work factor of such algorithm as high as you can deal with in normal use and the most cost effective attack is to run similar CPUs, that's the best case you can ever get. Argon2 hits this target pretty well. $\endgroup$ Jul 5, 2018 at 10:30
  • $\begingroup$ From the Argon2 paper § 6.4, it explicitly allows choosing a custom compression and hash function (as well as block size and number of slices), but it's not in the reference implementation only because the authors expect that most people want as few parameters as possible. $\endgroup$
    – forest
    Jan 8, 2019 at 12:40

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.

  • $\begingroup$ The purpose of BlaMka isn't to improve diffusion compared to blake2 rounds. Put simply, someone on the PHC mailing list observed that there weren't any silicon multiplier designs with significantly less latency than the latency of Intel's multiplication instructions. The idea, I think, was that utilizing multiplication would mean that run time of the hash function on ASICs would be closer to those on a server. The BlaMka permutation used in Argon2 was borrowed from Lyra2. (or Lyra1?) "Multiplication hardening" was to complement memory-hardness. ASICs would need to keep things in memory longer. $\endgroup$ Jan 10, 2019 at 4:20
  • $\begingroup$ @FutureSecurity Thanks. I've edited my answer to correct that. $\endgroup$
    – forest
    Jan 10, 2019 at 4:23
  • $\begingroup$ I can't search the mailing list archive. But I found from page 15 of the Argon2 version 1.3 paper "Our motivation was to increase the circuit depth (and thus the running time) of a potential ASIC implementation while having roughly the same running time on CPU thanks to parallelism and pipelining". From the Lyra2 v3 paper "The interest of including multiplications on the underlying function is that ... the performance gain o?ered by hardware implementations of this operation is not much higher than what is obtained with software implementations running on x86 platforms" $\endgroup$ Jan 10, 2019 at 4:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.