Kurt Fitzner

The idea of "PIM" is just so different for argon2id vs PBKDF. Part of the problem has been trying to shoehorn argon2id's setable parameters into the pbkdf single-iteration paradigm.

The concept of a single "PIM" is, I think, not truly compatible with Argon2id. Not without handicapping the best features of argon2id. Your typical key derivation will add about 20-bits of effective strength to a password. After that, for every added bit of effective strength you want to add, costs you double the processing time. One of the strengths of argon2id is the ability to add parallelism to this process. You get a free bit of effective password strength ever time you double the cores. Throwing...

The concept of a single "PIM" is, I think, truly compatible with Argon2id. Not without handicapping the best feature of argon2id. Your typical key derivation will add about 20-bits of effective strength to a password. After that, for every added bit of effective strength you want to add, costs you double the processing time. One of the strengths of argon2id is the ability to add parallelism to this process. You get a free bit of effective password strength ever time you double the cores. PIM formulas...

Just tried out the beta. Following bugs still exist: 1) Preboot-authentication overwrites password with a single * to obfuscate the length, but it does not replace the PIM with a single * - this is a very long standing bug, having existed since the beginning of EFI. 2) Booting from the rescue disk does not read DcsProp from the rescue disk - it reads from the system drive's EFI folder. I also note that EFI bootloader is byte-for-byte identical with previous version. I take it then that Argon2id is...

For Argon2id, it shows up in the list of features for Windows but is conspicuously absent from Linux. Does this mean that Linux can no longer open a volume so created? If this is the case, then it needs to be noted in rather large print. Linux is a common recovery platform, and if it can no longer open a Windows container/drive/system-drive that uses argon2id, then people will need to know that before they make the switch.

A 512 bit hash doesn't offer any security margin in VeraCrypt over a 256 bit hash. The hash is used solely to derive the (256 bit) header keys from the passphrase. Where collision resistance is an issue, it's true that a hash of length n only offers n/2 bits of security. However hashes are not used in VeraCrypt in any way that exposes that limitation. Hashes are not used in VeraCrypt in a way that requires collision resistance. Blake2S is as secure as SHA512 in this context. If you ask me, more so....

When I boot from a rescue disk, if I select "V" to "Boot Veracrypt loader from rescue disk", it reads the DcsProp from my system hard drive. This makes me worry that it is also booting from the loader that is on the hard drive. Why is the VeraCrypt rescue disk loader reading the hard drive DcsProp and not the rescue disk DcsProp? Also there appears to be a bug in the current release where when you edit the bootloader configuration, it adds duplicated text to the end of the configuration. It duplicates...

Is there any plan to address the lack of discard / trim capability for VeraCrypt in Linux? Bug #1186. The documentation is explicit that discard is not supposed to be blocked.