Key file without password - Why using Argon2id?

[Beloumi]

I raise concerns about using a key file without a password, but if it's already being used that way, why is there a time and memory intensive function being performed afterwards? At least a randomly created key file should have enough entropy to use its hash as key. And if an attacker gets access to the key file, Argon2 is of no use either. Otherwise, the key-file-only scheme would at least have a performance advantage to compensate for the security disadvantage.

[samuel-lucas6]

Thank you for this important reminder. That's a very valid point and something worth changing in v4.

I say that just using a keyfile is less secure on the website here, but I should probably add a similar note to the Best practices page.

I'm not aware of a standard approach for dealing with keyfiles. My reasoning for Argon2 was because the first 64 bytes were being read from the keyfile previously rather than the entire file being hashed using BLAKE2b-512. If everything was indeed randomly generated, then I would use the keyfile bytes as input to a KDF, with a random salt per file.

Three questions I'd love your feedback on would be:

1. Would you recommend removing support for using a keyfile without a password?
2. Would you recommend enforcing randomly generated keyfiles?
3. Do you think hashing the whole keyfile is appropriate if randomly generated keyfiles are not enforced?

Lots of changes are planned for v4, but it's going to take a long time due to university work and me having to finish my own libsodium binding. If you spot any other design decisions that you think are worth changing, please get in touch.

[Beloumi]

I have not found any standards for keyfiles either. There are also not so many use cases.
I face similar problems with the File Lock PEA, Calendar Lock PEA...
To your questions:

1. I think there are reasonable use cases for a keyfile without a password, such as when the encrypted file is uploaded to the cloud and the keyfile remains on the device. If the keyfile is stored on an USB stick, using it without a password probably makes sense for lazy people as well. I only have concerns because not everyone thinks about it and the keyfile then sometimes lies next to the encrypted file.
   But I think this is an unsolvable problem for the developers.
2. I thought about it too and decided against it in the end. The problem is similar to the first one: not everyone has the time and leisure to do extensive research. Some may then make a bad decision and select short or even empty files. I decided against it mainly because it would then also be difficult to select a previously generated keyfile.
3. I think that simple hashing is not a critical point, at least if the file contains enough entropy, which is usually the case. The File Lock PEA processes the keyfiles in the same way (also with Blake2b). For very long or very short files, only a warning is displayed. KeePass also hashes the files (with SHA-256) if they do not match certain formats. TrueCrypt/VeraCrypt only process the first 1024 KB of a file (the hash function is homegrown). If the file contains enough entropy, that is surely enough.

To return to the original point: Argon2 is not useful for generated keyfiles. For selected files there may be rare cases where users select short (text) files. Then in principle a dictionary attack would be possible. But I think this scenario is very unlikely.

[samuel-lucas6]

Nice summary of keyfiles on your website. Thanks for listing Kryptor as well.

1. I agree. I think I'll keep supporting it.
2. I'm currently enforcing a minimum of 64 bytes. It may be worth excluding text files.

I will stop using Argon2 when the user just specifies a keyfile in v4.

[hakavlad]

At least a randomly created key file should have enough entropy to use its hash as key

What if I want to use a not randomly generated file? The key file does not always have high entropy. I believe that the KDF should apply to the final key (passphrase + keyfile digest), not to just the passphrase. Every piece of user input must be protected by KDF.

[samuel-lucas6]

You basically shouldn't be using keyfiles that are low in entropy, just like you shouldn't be using low entropy passwords/passphrases. A password-based KDF helps slow the attacker but doesn't improve entropy.

[hakavlad]

Applying KDF to the keyfile slows keyfile bruteforcing (maybe when the enemy guesses which files could be used as key). Isn't that enough?

[samuel-lucas6]

It's helpful, but it's still worse than using a high-entropy keyfile. A keyfile should really be equivalent to a symmetric key in/stored as a file. My approach in v4 matches KeePass, for example.