Argon2id creating key for cryptography, how acceptable is it to use the same salt for the same encryption operation?

Question

Everyone knows Argon2id is a slow hashing algorithm, and that's on purpose, all is good.

When creating an Argon2id object a lot of parameters are needed to be taken into consideration ultimately settling on a configuration that is strong enough but within the amount of time that you're willing to wait for the operation to happen.

I'm using Argon2id in a cryptographic application where I take a user password, generate a random salt of 32 bytes and use them to create a hash of a key to use for AES-GCM encryption.

I am currently generating 1 salt for 1 key per operation. An operation can encrypt 1 or n files, my current tests are running for like 550 files. Everytime I start an encryption operation, even if I'm using the same password, a new salt is generated, but is used for all files that will be encrypted within the operation.

An alternative generating a new salt, which would result in a new key for the same password for each file, which is obviously more secure, but painfully way more slower even when I run it with a degree of parallelism of 8 concurrent file.

The single key approach uses:

768 MB RAM

7 iterations

12 threads

This clocks at 3.3 seconds hashing operation that is done once and the rest is lightning fast (finished in less than 10 seconds with 8 files in parallel)

The multiple keys approach uses:

32 MB RAM

14 iterations

12 threads

This clocks at 400 ms hashing operations that are done for each file, those parameters provide a somewhat acceptable (finishes in nearly 2 minutes with a 8 files in parallel)

My rationale for using the same key per encryption operation was that you can consider the 'n' files (in this case 550) as a single zip file that has all of them, encrypted with 1 key, the security would be equivalent. If you are able to break the zip's encryption you get access to the 550 files, unless my logic is flawed.

I need an advice if the trade off in Argon2id parameters for unique salts and slower time is more worth it, or is my initial approach acceptable in the world of cryptography. Thanks!

Answer 1

As someone who maintains a file encryption program, I would recommend the ZIP file approach without compression for directories/subdirectories. Then you derive one key to encrypt one file, eliminating such massive delay. This can have other benefits as well depending on whether you're encrypting files in chunks/hiding the exact file length with padding.

If you don't want to pack the files together (e.g. so they can be individually decrypted), you can generate one salt for an entire directory and store it in the parent directory (perhaps each subdirectory as a backup) as well as in each file. If the salt file gets deleted/renamed, you can decrypt each file individually using the salt stored in each file. This is like what Cryptomator does.

For the latter approach, I'd suggest the KEK/DEK paradigm. That involves randomly generating a data encryption key (DEK) to encrypt each file and then encrypting each DEK with the key encryption key (KEK) derived using Argon2. The encrypted DEK then becomes a header in each file.

In terms of other things, you could reduce the salt to 128 bits if you wanted to store less data because that's the standard size and enough. 3 seconds is also a bit much in my opinion for file encryption; I'd cap it at 1-1.5 seconds for usability sake. You can get away with much less if you expect passwords to be of a certain strength, which is why I presume age uses such little delay.

Answer 2

I recommend using the same salt $S$ for the same password $P$ in multiple encryptions, and a single Argon2id password-to-key derivation of $(P,S)$ into a single AES key $K$. That's best, because it allows to use higher cost parameters in Argon2id (e.g. that of the question's single key approach). That's safe, as long as a fresh and unique AES nonce $N_i$ is used for the AES-GCM encryption each file.

Each independently decipherable ciphertext file should contain (e.g. at start) the Argon2id parameters, $S$, and $N_i$, in order to allow decryption. Decryption can cache the last $K$, and reuse it when the inputs $(P,S)$ and parameters are unchanged in the next file.

Possible improvement: if it's wanted a unique key $K_i$ per file, that can be done by a secondary fast key derivation of $(K,N_i)$. That can be Argon2id with input and the lightest parameters possible $(p=1, m=8, t=1)$. This also limits to almost nothing the consequence of a repeated $N_i$ or counter overlap.

If no trusted CSPRNG is available to generate the $N_i$, that can be done by another secondary key derivation function, e.g. as Argon2id with input $(K,i)$ and the lightest different parameters possible, e.g. $(p=1, m=8, t=1, X=\mathtt{'N'})$