"Deriving key..." predates "Reading keyfiles..."

[hakavlad]

"Deriving key..." predates "Reading keyfiles...". Why? What is used to derive keys if the keyfiles have not yet been read? Expected behavior: key derivation occurs after obtaining the hash of the key files.

[HACKERALERT]

Deriving a key works solely off of the password (explained below). If keyfiles are being used, the hash of the keyfiles is XORed with the encryption key (from the password) to generate the actual encryption key. So you see "Deriving key..." first since a key is being derived through Argon2 with the password, and then "Reading keyfiles..." hashes the keyfiles, after which the key and the keyfile hashes are XORed to create the main encryption key.

This is necessary to be able to check if a password is correct. Comparing a password to just a standard hash (not Argon2) would make it easy to bruteforce, so the comparison must be done to the Argon2 hash of the password. Well, if we've already hashed the password with Argon2, then wouldn't it make sense to use it to save resources? Thus, the keyfile hash is combined with the encryption key after key derivation.

[hakavlad]

This is necessary to be able to check if a password is correct.

I think it's good practice to check the password+keyfiles combination, not just the password.

Well, if we've already hashed the password with Argon2, then wouldn't it make sense to use it to save resources?

It would be possible to receive DK after XORing, not before. This would protect the password and key files from brute force at the same time. It turns out that if the attacker knows the password, he can quickly bruteforce the final key. This seems like a weak point, but to me it's also an unexpected behavior: I expected the keyfiles and the password to be equally protected from brute force using KDF ("It's designed for maximal security, making absolutely no compromises security-wise").

[HACKERALERT]

I think it's good practice to check the password+keyfiles combination, not just the password.

Yeah, they're done separately. The password is compared to the Argon2 hash, the keyfile hash is compared to a SHA3-512 hash of the keyfile hash. Both are stored and compared individually so you will know which of the two are incorrect. You can try using a correct password but wrong keyfile to verify this.

It would be possible to receive DK after XORing, not before. This would protect the password and key files from brute force at the same time.

Then how would I tell whether it's the password that's wrong or the keyfiles? The password needs to be put through Argon2 before comparing so that it can't be bruteforced, and doing it again with the keyfiles would be somewhat unnecessary and double the key derivation time. Passwords have relatively low entropy, so Argon2 is a necessity. Keyfiles, on the other hand, are supposed to have relatively high entropy, and the built-in keyfile generator provides that already.

It turns out that if the attacker knows the password, he can quickly bruteforce the final key.

If the attacker knows the password, he still has to bruteforce through a 256-bit space to get the final key. As long as the keyfile is strong enough, this isn't anything to worry about.

[hakavlad]

Then how would I tell whether it's the password that's wrong or the keyfiles?

The user knows what password and key files were used for encryption. The attacker does not need to know this.

Keyfiles, on the other hand, are supposed to have relatively high entropy

There may be situations where an attacker may know many files that could have been used for encryption (for example, when accessing a disk on which encryption took place). In this case, the entropy of the key files does not matter much, and the lack of protection for the final keys (with KDF) can can help to quickly enumerate the file hashes.

If the attacker knows the password, he still has to bruteforce through a 256-bit space to get the final key.

Not always. See paragraph above.

[HACKERALERT]

Even if the attacker knows that the keyfiles reside on a disk with many files, Argon2 won't have that big of an impact. Sure, it may slow down an attacker from an hour to a day or maybe a week, but unless your keyfile is a needle in a haystack (1 in a trillion files), it won't stop the attacker from finding it within a reasonable amount of time. If the user leaks the keyfile on an unencrypted filesystem, that's kind of on them. Yes, Picocrypt tries to prevent footguns wherever possible, but it can't and won't prevent something outside of its control.

Sure, I can see some benefit of putting keyfiles (which should be secure, both physically and cryptographically) in front of Argon2, but it would break compatibility with previous volumes and I would rather not have that happen. I think it's okay to keep it as is.