# Can you correct my understanding of Argon2? [closed]

I'm a bit new to the cryptography field (completely new), and could really use your guidance.

Please, correct my understanding, as defined by the following statements.

1. The Argon2 Hash Generator has won the Password Hashing Competition, and is therefore believed to be the best solution at the moment for safely hashing passwords. Is is recommended to be used instead of bcrypt or pbkdf2

2. The Argon2 requires additional configuration, through parallelism factors, memory cost, iterations and hash length in order to be used in the most effective. However, default parameters are usually just fine.

3. The Argon2 also requires a 'salt' for security reasons - this one is meant to be generated using Cryptographically Secure Pseudo Random Number Generators (CSPRNGs for short), but any reasonably random value can be used here.

4. Some implementations of the Argon2 (such as this one), allow to secret keys and additional data to the function, but these are optional and are not required for the resulting hash to be secure.

5. Since any reasonably random value can be used as a salt, the result of another hashing function, such as Blake3, could also be used as a salt.

6. If I want to store both email hash and password hash securely in a database, for the potential attacker to have as little information about the user as possible, I could:

1. Store the registration date (RD) of a user
2. Generate the Argon2 hash of the email address, using the Blake3 hash of the RD as the salt
3. Generate the Argon2 hash of the password, using the Blake3 hash of the Argon2 hash of the email as the salt
7. The point above would not compromise the security, offered by the Argon2 hash, and would make it quite difficult for anyone, even those with a direct access to the database and the source code, to figure out what the email and the password of the user actually are - but would make it trivial to verify whether the user's input was correct or not

Any criticism, comments, thoughts, opinions (grounded in facts) - are more than welcome.

Correction: as Marc pointed out, 6.2. doesn't make any sense - it would make it (nearly) impossible to look the email up for a registered user. If we substitute the step 6.2. with a random scrambling of the user's email - such as Fisher-Yates Shuffle, repeated for X iterations - to make it consume time, using a random generator from this function, with a seed number derived from the email once again, would the rest still make sense?

• Comments are not for extended discussion; this conversation has been moved to chat. – Maarten Bodewes Jun 6 at 10:46
• I’m voting to close this question because this is seeking help for a specific use of Argon2. That the accepted answer provides this is nice, but it doesn't address the question about understanding Argon2 and is not of much use to other users. – Maarten Bodewes Jun 6 at 10:50

A) Don't hash Email. Store it as plain text or don't store at all.

If hashed, then looking up will be impossible. One would need to iterate through every single record in the database. On average 50% records need to be tested each time. In case there are 1 000 000 users, for every login case the application will need to check on average 500 000 records. Hashing needs to be expensive. Suppose it takes 1s. It means, checking of a single login will take 500 000 s, which is about 6 days. Even for a small database with 1 000 user this will take 500 s = more than 8 minutes to check login every time user logs in. No user will accept it.

B) Store login ID as a plain text, exactly as entered by user, without any transformation and obfuscation.

If you use any transformation, it must produce each time the same result, otherwise you will not be able to look up login in the database. If the result is always the same, then also an attacker will be able to easily generate the same code. Means, not more security, but more obscurity and thus more error prone.

C) Where random data are needed, use random generator, don't add anything else.

The RD is not random. Thus Blake3(RD) is also not random. Thus the salt is not random. Instead, use random generator. Furthermore, adding complexity or making an algorithm more obscure does not make it more secure, not even a little.

Also don't make Email address or any other fixed data a part of the secret. Such data are not really random. Each user has some more or less limited number of such attributes (nobody generates a new Email address every day). That's why such data don't give much entropy. But using them makes the algorithm more obscure and gives a false feeling of security.

D) Try to keep an algorithm as simple as possible.

Think of Kerckhoffs's principle. Adding obscurity does not give any more security. But more obscurity means more complexity in the implementation, which makes implementation more error prone and thus actually less secure.

E) Separate different goals clearly. Don't mix them.