Repository navigation
Three months of waiting and Mounting with Password Cache Issue is STILL BROKEN! #1969
Description
I posted about this Mounting Password Cache issue back in July #1831 and it seemed like the issue was related to #1815 which was noted to have a fix in v1.26.30. But here we are, still doing the same thing. Try to mount the volume using the password cache and VC just sits there indefinitely. Oh, but at least we have a "Cancel" button now.
What's with all the regressions these days? Seems like devs are trying to over-complicate things for no reason. It's not like VC has changed much over the years. Is there some goal to make VC as terrible as Microsoft does with Winblows 11? I mean things have gotten so bad that now we can't even have a proper "Setup" binary posted in the releases because of XYZ issues.
Not trying to sound ungrateful, but just genuinely curious of what's going on. Hate to see such a great project regressing so much these days. Now I'm having to use a version that's from two builds ago, just to get a basic feature working correctly. Even if I ignore this bug and just install the new version, I still won't have access to the "Activate encryption of keys and passwords stored in RAM" feature since there isn't a proper installer available and that feature won't work with the Portable version!
Activity
flatstik commentedon Oct 27, 2026
This looks like the same expensive path as #1815, reached through the password cache instead of favorites: the 1.26.30 fix for #1815 (9cabe0d) only stopped Linux favorites from inheriting credentials, and does not change the cache.
On Windows, mounting with an empty password tries every cached password (
ReadVolumeHeaderWCacheWithAbortinsrc/Common/Cache.c) with KDF autodetection and the PIM cached with that entry. The cache does not store which KDF opened the volume, so autodetection runs Argon2 for every cached password that does not match, inside the driver. With a PIM above 31 that is 1 GiB and 13 + (PIM − 31) passes per attempt (get_argon2_params), which explains why it only happens with PIM > 31 (#1831) and only since Argon2 was added to autodetection.A possible fix: cache the PRF that succeeded together with the password and PIM, and under autodetection try each cached password only with its own PRF. A wrong cached password then fails at the cost of one KDF.
I do not have Windows or macOS to test a fix on, so I am not sending a patch for the Windows cache.
Until then, selecting the volume's KDF explicitly instead of Autodetection avoids the Argon2 attempts.
ColorfulResponse commentedon Oct 27, 2026
@flatstik, thank you for the insight. When I mount the volumes for the first time, I always manually select the KDF and then cache the password and PIM. However, when I unmount and remount the volume, it just sits there trying to mount indefinitely. As I'm sure you're aware, then you click on "Mount" and you have passwords cached, VC will just jump into trying to mount the volume, it doesn't prompt you to manually select the KDF. So I'm not 100% what you mean by selecting it. Do you mean setting it in the "Default Mount Preferences" in VC settings?
flatstik commentedon Oct 27, 2026
Yes: Settings > Default Mount Parameters... > KDF. When you click Mount with cached passwords, that KDF is used for the cached passwords (a
/hashcommand line option overrides it), so with your volumes' KDF selected there instead of Autodetection, the cached passwords are no longer tried with Argon2.It applies to every mount, so a volume with a different KDF then needs its KDF selected in the password dialog. I read this from the code; as said, I can't test it on Windows.
flatstik commentedon Oct 27, 2026
For Linux and macOS, #1972 caches the KDF with each password and tries each cached password only with it under autodetection. The Windows driver cache is not changed there.
ColorfulResponse commentedon Oct 28, 2026
@flatstik, I can confirm that by pre-selecting the KDF via "Default Mount Parameters" resolves the issue. However, this brings me to a new issue when trying to mount a volume that ISN'T using my default KDF. For example, if I set my default KDF to SHA512, I can mount two volumes that are using SHA512. But if I mount another volume that's using SHA256, I am not able to remount that SHA256 volume using the cache. VC will just take me to the password dialog screen after it attempts to mount the volume using the cache. Either way, this is all just a band-aid for something that needs a proper fix. But thank you for giving me a temporary solution.
Unix: try cached passwords only with the KDF they opened a volume with
Unix: try cached passwords only with the KDF they opened a volume with
Unix: try cached passwords only with the KDF they opened a volume with