Encryption algorithms support cascading, but key derivation algorithms lack it.

[fzxx]

Desired behavior

It is recommended to use Argon2 + HKDF-SHA3-512 to maximize key security as well.

Screenshots/Mockup/Designs

Argon2id ──► IKM ──► HKDF-SHA3-512
                           │
                           ├──► AES Key
                           │
                           ├──► Twofish Key
                           │
                           └──► Serpent Key

Stronger combination

Argon2id ───────────┐
                    │
                    ▼
PBKDF2-SHA-512 ──► IKM ──► HKDF-SHA3-512
                          │
                          ├──► AES Key
                          │
                          ├──► Twofish Key
                          │
                          └──► Serpent Key

[idrassi]

Thank you for the suggestion.

I don't think this should be implemented, because it assumes the password KDF derives the encryption keys which is not true.
The KDF only derives the header key that decrypts the volume header. The master keys themselves are generated by the CSPRNG and stored inside that encrypted header: they're never derived from the password.

So the cipher cascade analogy doesn't carry over. A cipher cascade protects against a break of one cipher while the KDF's only job is to make guessing the header password expensive. Chaining KDFs doesn't add that, it just sums the per-guess costs.

HKDF-SHA3-512 is essentially free (pure expansion), and PBKDF2 only adds compute-hardness that GPUs/ASICs defeat far more easily than Argon2id's memory-hardness. Under a fixed mount-time budget, that time is always better spent on Argon2id.

Per-cipher key separation also already exists: Argon2id outputs 192 bytes (two 256-bit keys each for AES, Twofish and Serpent) which VeraCrypt splits per cipher, so an HKDF step adds nothing.

If you want a higher per-guess cost, raise the Argon2id PIM. If you have a concrete construction with a demonstrable advantage over Argon2id at an appropriate PIM, I would be happy to discuss it.

[fzxx]

Thank you for the suggestion.

I don't think this should be implemented, because it assumes the password KDF derives the encryption keys which is not true. The KDF only derives the header key that decrypts the volume header. The master keys themselves are generated by the CSPRNG and stored inside that encrypted header: they're never derived from the password.

So the cipher cascade analogy doesn't carry over. A cipher cascade protects against a break of one cipher while the KDF's only job is to make guessing the header password expensive. Chaining KDFs doesn't add that, it just sums the per-guess costs.

HKDF-SHA3-512 is essentially free (pure expansion), and PBKDF2 only adds compute-hardness that GPUs/ASICs defeat far more easily than Argon2id's memory-hardness. Under a fixed mount-time budget, that time is always better spent on Argon2id.

Per-cipher key separation also already exists: Argon2id outputs 192 bytes (two 256-bit keys each for AES, Twofish and Serpent) which VeraCrypt splits per cipher, so an HKDF step adds nothing.

If you want a higher per-guess cost, raise the Argon2id PIM. If you have a concrete construction with a demonstrable advantage over Argon2id at an appropriate PIM, I would be happy to discuss it.

Cascading KDFs serves to mitigate the risk of vulnerabilities in individual algorithms, and the current guessing cost is adequate.
However, it is suggested to increase the maximum memory limit for Argon2id's PIM to 4 GB, and raise the parallelism to 2 (since attackers can leverage multiple hardware devices; limiting parallelism only slows down regular users). Additionally, the time-cost growth curve should be optimized: the current approach of increasing iterations by 1 every 3 steps when PIM ≤ 31 is too gradual; it could be changed to every 2 steps or switched to linear growth to enhance security at low PIM values. @idrassi