Argthtjtr

Is using Argon2 for both password storage and key derivation secure? I'm planning on using different salt values, of course.

The basic concept is something like this:

Alice has some secret data ($data_e$) on her account. It's encrypted with an Argon2 derived key from her password, using a random salt.

$$ k = operatorname{Argon2}(text{password}, text{salt}_1, text{iteration})$$
$$ text{data}_e = operatorname{E}_k(text{data})$$

Alice's password is stored as an Argon2 derived key from her password, using a random salt. When Alice (or an adversary) wants to log in, a key is derived from the input using Alice's password salt and checked for a match.

$$text{storedPWD} = operatorname{Argon2}(text{password}, text{salt}_2, text{iteration})$$

1. Should the secret data be encrypted with Alice's raw password?


2. Should her data to be encrypted with a random key encrypted with her raw password? With a key derived from her password?

You should assume that Alice is a trained system administrator who understands the risk of having a weak password. The password will have at least 12 characters, will include capital and small letters and have numbers.

Also assume that the login system is bruteforce-resistant, but think about the possibility of a database breach.

Thanks in advance.

Should the secret data be encrypted with Alice's raw password?

As a general rule of thumb:
A password should only ever be fed into a password hashing scheme (PHS) such as Argon2, scrypt or bcrypt, never into anything else!

There are multiple reasons for this:

• Passwords need special processing in the form of complexity parameters.


• Passwords need external (high-entropy) sources of uniqueness / randomness to be mixed in.


• Passwords should be allowed to be long and variable-length, most cryptographic primitives have very specific expectations on key lengths.


• Passwords usually aren't randomly uniformly distributed bit strings (eg the highest bit is rarely set), which most encryption algorithms assume for their keys.

Should her data to be encrypted with a random key encrypted with [...] a key derived from her password?

Yes. Another good rule of thumb is:
Only ever perform one password hashing per user, but give it all the resources you can spare.

The idea behind this is:

• If you chain derivations and an attacker can validate whether they got the correct value for an intermediate stage, they only need to compute the last stages once, instead of once for all passwords.


• If you don't expose intermediate values, you effectively created a new composite hashing scheme.


• If you perform two independent derivations, you are likely to lower the resources required for each individual one and it is sufficient for the adversary to only break the weakest one and get the other one(s) "for free".

The rest is similar to smrt28's answer:

Encrypting a high-entropy key with a password-derived key allows your users to change the password without you having to re-encrypt the entire data, which may be costly in terms of CPU-time and I/O-time if you have a lot of data.

Additionally, if you use authenticated encryption (AE) using the derived key for the high-entropy key, you essentially get secure password confirmation "for free", as the scheme will very clearly report an error if the password and thus the derived key is wrong. Additionally, you can cryptographically bind derivation parameters like salt and iteration count to successful decryption using the associated data input of most AE schemes.

So in formulas: $text{derKey} = operatorname{Argon2}(text{password}, text{salt}, text{iteration}), c=operatorname{AE}_{text{derKey}}(text{MK})$ and now if one tries to decrypt with the wrong password, the AE-scheme will report an authentication failure as the key is wrong and if it is right, it will just return the correct master-key.

Try to think like a hacker...

Consider the hacker got control over the storage and consider Alice has a relatively weak password. Relatively weak in this context means the hacker cannot break it by brute force from Argon2 hash, but he can break it if he got just a basic single (for instance) SHA256 hash.

If you encrypt Alice's data by the password, the hacker can crack the data by brute force (brute force breaking AES is as easy/hard as breaking SHA256). Also, there is a disadvantage that if Alice changes her password, you would have to re-encrypt her data.

If you encrypt a random master-key by the password and use the master-key to encrypt Alice's data, there is no difference in security, just you don't have to re-encrypt data if Alice changes her password. You would have to re-encrypt just the master-key.

If you encrypt a random master-key by storedPWD, then the hacker has the key available easily in the database.

IMO you should calculate two Argon2 hashes with a different salt each and use one to verify a password, the second one to encrypt data.

I think the best solution would be: x=Argon2(password) and then store SHA256(x || salt1) in database and use it for password verification, SHA256(x || salt2) for encryption. Or even better, Argon2 has the result length as a parameter. Just instead of 256 bits let Argon2 derive 512 bits and use first 256 for password verification and the second 256 for encryption.