[Linux 1.26.29] Unable to mount hidden volume

[Nojisumire]

Admittedly I'm not on a great laptop, and can't currently afford a new one. Anyway, when trying to mount a hidden volume on Linux (Mint 22.2), for the first time since updating to the newest version, the "Attempting to mount..." progress bar just kept going on and on..., well beyond 10m, which was somewhat unusual, since it's usually reasonable (maybe 1m or so) on the previous version, or told me that I got my password wrong.

Only thing I can state is that I use a password with a high PIM. (Not greater than 1,000.)

Mounting a non-hidden volume worked fine however. (Password, default PIM)

For now I've had to downgrade back to the previous version.

Expected behavior

Able to mount hidden volumes, or at least able to mount hidden volumes in a reasonable timeframe.

Observed behavior

I did notice that /usr/bin/veracrypt --core-service ended up spiking >1GB. The CPU usage was ~25%. (Though this was after I terminated the program because it had frozen entirely, then I rebooted.)

Compared to the previous version 1.26.24 (Ubuntu 24.04), the RAM stays below <100MB, but the CPU usage was also the same when trying to mount the volume. (~25%)

Your Environment

Please tell us more about your environment

VeraCrypt version: 1.26.29 Ubuntu 24.04

Operating system and version: Linux Mint 22.2, i3-2348M, 4GB RAM

System type: AMD64

[idrassi]

Thanks for the report. This is caused by the Argon2id KDF added in VeraCrypt 1.26.29.

When the KDF is left on Autodetection and a custom PIM is entered, VeraCrypt has to try all possible KDFs.
For hidden volumes, VeraCrypt first checks the normal/outer volume header, and only after exhausting those candidates does it check the hidden volume header.

With high PIM values this becomes problematic now that Argon2id is part of autodetection. The same PIM value that is reasonable for PBKDF2 can be extremely expensive for Argon2id. For example, Argon2id reaches 1024 MiB of memory at PIM 31, and above that the time cost increases linearly. This explains the >1 GB memory usage and long single-core CPU activity you observed.

As a workaround, please select the exact KDF used by the volume (e.g. SHA-512) instead of leaving KDF on Autodetection.
For command line usage, pass the corresponding --hash=... option together with your PIM. This avoids trying Argon2id when the volume was created with a PBKDF2-based KDF.

Of course the current behavior is not good. We need to improve the autodetection path so high-cost Argon2id trials don't silently block hidden-volume detection. I will keep this issue open while evaluating the best approach.