1

Let's assume I would like to secure passwords using a modern KDF such as Argon2. The flow of information would look like this: $hash,$salt = argon2id($password, $salt).

Is there any advantage to first hash the password using SHA256/512, like so $hash,$salt = argon2id(sha256($password), $salt)?

Joe D.
  • 11
  • 2
  • Argon2 seems pretty young as cryptographic functions go. Has this been recommended by any standards bodies, yet? – nbering Jan 18 '19 at 11:30
  • From what I could gather, [OWASP recommends using Argon2](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet#Leverage_an_adaptive_one-way_function) for new developments. However, I am not asking "Is Argon2 okay to use?" but "Is there an advantage to combine SHA-256 with Argon2" (or any other hash+kdf). – Joe D. Jan 18 '19 at 11:34
  • 1
    I was asking for my own curiosity, than challenging the validity of the question. This might be better asked on https://crypto.stackexchange.com/, since the implications of the question are related to the effectiveness of cryptographic functions, rather than infosec per se. I'd caution against stacking crypto primitives without guidance from cryptographers though... it sometimes causes more harm than good. – nbering Jan 18 '19 at 11:38
  • That was my own intuition as well (aka. "less is more"), though I have to admit that I was not aware that there was a dedicated crypto.SE. – Joe D. Jan 18 '19 at 11:40
  • 1
    @nbering It's 5 years old. It's been scrutinized more than the usual alternatives. It's made with components that are well understood. There isn't any good way to capitalize on any flaws in the new stuff in Argon2 because the output is derived by hashing the entire buffer using blake2b. (There would have to be really spectacular, really obvious shortcuts for it to be weak. Even MD5 or SHA-1 aren't bad enough to cause problems if they were used instead of blake2. Anything one-way-ish would make it cheaper to guess and check passwords than try to go from hash to a MB or GB input to a password.) – Future Security Jan 19 '19 at 02:40
  • @nbering Even if it were plausible there were some huge unseen design flaw, it would be no worse than the alternatives. (Which aren't aging well.) Argon2, scrypt, bcrypt, md5crypt, s2k, and other iterated constructs are going to be at least as brute-force-number-crunchy as PBKDF2. Scrypt and Argon2 will be at least as GPU hard as bcrypt. Argon2 is going to exploit memory hardness for defensive purposes at least as well as scrypt. We should use Argon2 now. We don't want to wait until Argon2 is also obsoleted by its successor before adopting Argon2 instead of a newer algorithm. – Future Security Jan 19 '19 at 02:57
  • @FutureSecurity Argon2 has better memory hardness than scrypt, which has severe time-memory tradeoff attacks. Argon2d and Argon2id have far superior resistance to TMTO. – forest Jan 19 '19 at 04:45

2 Answers2

2

From looking at its specification, the first step of the argon2 algorithm is to hash the password with the BLAKE2b hash function. Therefore, it is useless to first hash the password with SHA2 before passing it to argon2id.

Community
  • 1
A. Hersean
  • 10,046
  • 3
  • 28
  • 42
2

Key derivation functions use hashing functions internally. The best and clearest example of this is PBKDF2 where you can also pick the hashing function that you'd like to use (this is typically PBKDF2-HMAC-SHA256 but can be changed to use other cryptographic hash functions).

Argon2 internally uses BLAKE2b (see 3.1 in the Argon2 specs) which is more performant than SHA256 and most common hashing functions.

BLAKE2b is optimised for x64 platforms which fits exactly the requirements of a password hashing scheme. SHA512 would also be ok, but SHA256 would be much slower in software and due to the fact that SHA256 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.

So, in general, in itself you'd not get a major improvement security wise over plain Argon2 - which, despite being a relatively recent algorithm, it meets all requirements of a password hashing scheme and has been vetted by the crypto community.

There's an article on Medium that better explains why you should use Argon2 100% of the times on new systems.

XCore
  • 244
  • 1
  • 8
  • Actually, with PBKDF2 there _is_ a benefit to pre-hashing. PBKDF2 hashes in the original password at each step; if the password is long enough to require hashing multiple blocks, that makes each step take longer. Pre-hashing it will make it only take longer for that initial hash. – AndrolGenhald Jan 18 '19 at 22:44
  • Reading the RFC again, it doesn't actually seem like a longer password should make a difference if optimized correctly, the implementation I looked at must simply not have accounted for that edge case. – AndrolGenhald Jan 18 '19 at 23:11
  • SHA-512 would be okay in that it would not reduce memory hardness, but it is absolutely not something you would want to do. I wrote about that [in an answer on Crypto.SE](https://crypto.stackexchange.com/a/66356/54184). In fact, the primary use of the hash function in Argon2 is actually a heavily reduced-round variant of Blake2b, nicknamed BlaMka, which uses only two rounds and combines multiplication with addition in the round function. – forest Jan 19 '19 at 04:46
  • Also, I don't think Bitcoin mining ASICs are relevant at all. They are designed only for mining Bitcoin blocks using SHA-256d. You just give them a block and a nonce and they tell you if you've found a block or not. They aren't simply SHA-256 accelerators, but are highly application-specific (hence the term ASIC). – forest Jan 19 '19 at 08:12
  • @forest sorry, meant FPGAs... Indeed you can't really repurpose an ASIC but you can repurpose an FPGA. – XCore Jan 19 '19 at 10:27
  • @XCore FPGAs aren't specific to any one kind of hash. There is no such thing as a SHA-256 FPGA, just an FPGA programmed for SHA-256. You could just as trivially repurpose it for any other hash. – forest Jan 19 '19 at 10:35
  • @forest surely. What matters is the way SHA256 is implemented/optimised to run on it. Anyone can write a SHA256 implementation but, given the market cap of BTC and other coins, people have considerably spent a lot of time optimising SHA256 on FPGA/GPU/CPUs. That hasn't really happened for Argon2. Also adding SHA256 or 512 or any other non memory hard function won't really give you many security benefits. – XCore Jan 19 '19 at 10:40
  • @XCore I don't think anyone seriously uses FPGAs for it instead of ASICs. They are so, so much slower. And an optimized version of any hash can be trivially written for an FPGA, CPU, or GPU (not an ASIC though, as that requires expensive hardware design unique to each component). But you are right that a memory-hard KDF is a far better idea than any other hash. My point is just that SHA-256 being used by optimized Bitcoin ASICs does not have any impact on its use as a hash since Bitcoin ASICs cannot be repurposed as SHA-256 password crackers, despite Bitcoin mining involving SHA-256. – forest Jan 19 '19 at 10:44