Which of the two types of Argon2 is the best for password-based key derivation?
In short, as said by draft-irtf-cfrg-argon2-03;
If you do not know the difference between them or you consider side-channel attacks as viable threat, choose Argon2id.
Argon2d is faster and uses data-depending memory access. Data dependency immediately enables side-channel. This is suitable for cryptocurrencies and applications with no threats from side-channel attacks.
Argon2i uses data-independent memory access and this is preferred for password hashing and password-based key derivations.
Argon2id In the first half of the first iteration works as Argon2i and the rest works as Argon2d. This enables both side-channel protection and time-memory trade-off.
How can I use Argon2 with a predefined salt?
From a library for Argon2
Usage: ./argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m memory] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)]
Password is read from stdin
Parameters:
salt The salt to use, at least 8 characters
-i Use Argon2i (this is the default)
-d Use Argon2d instead of Argon2i
-id Use Argon2id instead of Argon2i
-t N Sets the number of iterations to N (default = 3)
-m N Sets the memory usage of 2^N KiB (default 12)
-p N Sets parallelism to N threads (default 1)
-l N Sets hash output length to N bytes (default 32)
-e Output only encoded hash
-r Output only the raw bytes of the hash
-v (10|13) Argon2 version (defaults to the most recent version, currently 13)
-h Print argon2 usage
The libraries handle this for you. You just provide a random salt and store it, if you want to get the same result again, use the same salt.
Is there a point in using a salt that is freely accessible (if my data are stolen)?
Normally, you can store these values - salt, iteration, memory usage, parallelization, output size - with your data. If you really want to keep them separately from the storage you can do it, but there is no need. It is designed to be secure even if they are known by an attacker. When servers are attacked, all of these parameters are also acquired by the attackers. Salt is used against rainbows tables. Remember Kerckhoffs's principles, only the key is secret.
Some people suggest making the salt a secret to increasing the security of their product, however, remember that if your security relies on the security of the salt, there is a real problem with your design.
can somebody shed light on how Argon2 can be used as a password-based key derivation function?
There is a Key Encryption Key (KEK) methodology that is common with disk encryption utilities. Let say a file encryption key (FEK) is randomly generated by a good random source. Then your strong password is used to derive the KEK with Password-Based Key Derivation Function (PBKDF), here in your case Argon2id.
$$\text{KEK} = \operatorname{Argon2id}(salt, password)$$
Use your KEK to encrypt FEK and store it on your target ( your computer or phone). $$FEK^* = \operatorname{AES}\hbox{-} Enc_{KEK}(FEK)$$
Now, you want to encrypt a file, use your strong password to generate the KEK
$$\text{KEK} = \operatorname{Argon2id}(salt, password)$$
and use the KEK to decrypt your FEK from the storage.
$$FEK = \operatorname{AES}\hbox{-} Dec_{KEK}(FEK^*)$$
Encrypt the file with an authenticated encryption mode like AES-GCM or ChaCha20-Poly1305 and store it on your computer or cell-phone.
$$\text{EnryptedFile, ATag} = \operatorname{AES}\hbox{-} GCM\hbox{-}Enc_{FEK}(\text{file})$$ where ATag is the authentication tag. Never decrypt a ciphertext if there is tag missmatch, halt!
You need to keep FEK only in system memory and purge it when the operations are finished.
The benefits of this approach;
- You only need to memorize your strong password
- The Encrypted FEK and Argon2id parameters can be stored together with the files or some other suitable place for your choice.
- For each file, you can generate a new random FEK.
always uses a random salt for hashing".
It is for each file or password not for every run of Argon2 run. You need to derive the same results if you want to compare the hash of the file or generate the same key, you have to use the same parameters including the salt. And to not forget that salt, you must write it somewhere.
