VeraCrypt 1.26.29 Argon2id setup: stop using legacy PBKDF2

Since people are finally noticing the 1.26.29 update, we need to talk about moving away from legacy PBKDF2 (SHA-512/Whirlpool). If you’re still formatting headers with old KDFs, your setup is basically a generation behind against specialized GPU/ASIC cluster cracking.

Argon2id is a memory-hard function. Unlike traditional algorithms that can be crunched at lightning speed with raw GPU compute, Argon2id forces the cracking hardware to allocate actual RAM to every single guess. It completely tanks parallel processing speeds for forensic tools.

The VeraCrypt implementation is a bit weird compared to standard CLI tools, so here is how to actually configure it properly without messing up your threat model:

1. KDF Selection

Choose Argon2id. Avoid regular Argon2i or Argon2d. Argon2id is the hybrid approach that balances defense against side-channel attacks and GPU brute-forcing. (Note: VeraCrypt UI now calls this KDF instead of PKCS-5 PRF).

2. The Thread and RAM Trap

In standard Argon2id, you tweak threads and memory independently. VeraCrypt doesn't do that. For cross-platform stability, thread count is hardcoded to 1. Everything else—your RAM usage and iterations—is driven entirely by your PIM (Personal Iterations Multiplier).

Here is how the PIM scales your RAM allocation under the hood:

○ PIM 12 (Default) = 416 MiB RAM, 6 Iterations

○ PIM 15 to 30 = Scales up the RAM buffer heavily

○ PIM 31 = Maxes out memory hardness at 1,024 MiB (1 GiB) RAM, 13 Iterations

○ PIM 32+ = Capped at 1 GiB RAM, but keeps adding more iterations (time delay)

3. Choosing your PIM

Don't use the default. A custom PIM is crucial here because if an adversary doesn’t know your exact PIM value, they can’t even configure their automated cracking tools to attempt a guess. For non-system volumes, aiming for a PIM between 15 and 31 is the sweet spot. It forces a heavy RAM requirement while keeping your mount time under 3-4 seconds on modern hardware.

4. A reminder on Hidden Volumes

If you're using an inner/outer volume setup, encryption doesn't save you from a compromised host. Never decrypt your outer volume on a machine connected to a live network or the clearnet. If the primary OS has malware, your keys are getting dumped straight from memory anyway.

Anyone benched this on modern hardware yet? Curious what PIM values or RAM configs you guys are running for your threat models.