This project has moved and is read-only. For the latest updates, please go here.
1
Vote

Long delay in mounting volume before password prompt

description

When I try to mount a volume in the VeraCrypt UI it first pops up the "Please wait... This process may take a long time dialog" before asking me for the password. I assume it's trying to mount the volume using a cached password. I know this is inherited from TrueCrypt, but in TrueCrypt there was no noticeable delay. In VeraCrypt the delay is very noticeable and very annoying. Can it show the mount dialog immediately and then only try cached passwords if the user clicks OK, leaving the password field blank? I think the annoyance of having to click an extra button would be much less than the annoyance of this delay.

comments

Enigma2Illusion wrote Oct 18, 2015 at 8:58 PM

In my opinion, this proposal would confuse users as to why they are being prompted for the password dialog box when they purposely enabled password caching.

You can wipe your password cache through the GUI or setting-up the hot key in VeraCrypt to wipe the password cache so that subsequent mounts will prompt for the password immediately.

RealityExists wrote Oct 29, 2015 at 8:51 AM

I don't want to wipe the password cache, because I still want to mount some volumes with a cached password. However, I also want to mount other volumes, which don't have a password cached.

Yes, I can see some users being confused by it. You could put some gray text in the background of the password textbox that says something like "Leave blank to try mounting using cached passwords".

Enigma2Illusion wrote Oct 29, 2015 at 2:31 PM

Here is another idea that would avoid users getting unnecessarily prompted for the password dialog box, add another option to the Volume menu list (click on the word Volume at the top left of the GUI) "Mount Volume without Cache Passwords" and add this option to the hot-keys.

Also add "Mount Volumes with Options" to the hot-keys.

RandomNameforCode wrote Nov 1, 2015 at 8:53 PM

Why is the delay longer for cached passwords? To find out whether the currently needed password is cached, no hash computation is needed, is it? - And afaik hash computation is the only operation that takes longer in VC than in TC.

Enigma2Illusion wrote Nov 2, 2015 at 12:08 AM

RandomNameforCode wrote:
To find out whether the currently needed password is cached, no hash computation is needed, is it?
.
In order to determine if the any of the cached password, up to five passwords, VeraCrypt has to perform the same hash algorithm for each password and each type of hash algorithm in parallel to determine that none of the cached passwords are correct for the volume you are mounting.

RandomNameforCode wrote Dec 5, 2015 at 1:46 AM

Why does TC rehash the password each time? Why not cache the result of the hash instead of the password?
From a security perspective it does not matter whether an attacker obtains the password or the derived hash. In fact, the password can be entered in VC, but the hash result cannot be used in combination with VC - so It is even a little more "secure" as the attacker has to implement some kind of bypass in VC or with other libraries.

RealityExists wrote Dec 5, 2015 at 9:58 AM

I didn't even consider that, but that's a good point. If it could cache the hash that would solve this delay issue without changing the user workflow at all.

Enigma2Illusion wrote Dec 6, 2015 at 4:03 PM

The hash, salt and number iterations through the hash algorithms are derived from the password, keyfile(s) and PIM. There is no value in caching the hash value of the volume since you do not want to open a security hole and the code works by checking for an ANSII value of "VERA" to determine that it has the correct password.

https://veracrypt.codeplex.com/wikipage?title=VeraCrypt%20Volume%20Format%20Specification

RealityExists wrote Dec 6, 2015 at 5:40 PM

I don't understand, what exactly is the security hole that would be opened? Could you explain?

The "value" in caching the hash would be to save the time required to compute it when opening volumes using a cached password (what this issue is about).

Enigma2Illusion wrote Dec 7, 2015 at 2:18 PM

If you cache the hash value, you are opening the potential of an attacker getting the value from memory or if flushed to paging/swap file, hibernation file that allows then to unlock the volume(s) by then retrieving the encryption key from the header key. Correct?

RealityExists wrote Dec 7, 2015 at 6:19 PM

Right, but how is that different to caching the password?

If anything, the impact of having the hash stolen by an attacker is less (as already pointed out by RandomNameForCode), since the hash can only be used with VC, while the password could potentially be used elsewhere as well.

Enigma2Illusion wrote Dec 8, 2015 at 7:07 PM

It just occurred to me that caching the hash has no benefit since each volume's hash is unique if you use the same password, keyfile(s) and/or PIM.

Enigma2Illusion wrote Dec 8, 2015 at 7:30 PM

typo: missing word and clarity

It just occurred to me that caching the hash has no benefit since each volume's hash is unique even if you use the same password, keyfile(s) and/or PIM for each volume.

RealityExists wrote Dec 8, 2015 at 7:55 PM

Oh, right, that makes sense! Never mind the hash then. The original issue remains, of course.

RandomNameforCode wrote Dec 14, 2015 at 12:26 PM

RealityExists slightly misunderstood my point: With the hash, An attacker cannot even use VC to mount a volume (as you can only enter a password you would have to modify VCs code to use the hash)

So the KDF input includes a volume-specific salt, which is part of the volume header?
And caching is for mounting more drives with the same parameters? I thought the cache was introduced to re-mount a volume.

Nevertheless a "use Cache"-Button in the mount dialogue would be much nicer than a cache-attempt followed by the mount dialogue .

How does the cache handle the KDF-selection? It should at least keep the KDF used for the last successfull mount.

codegrind wrote Jan 8, 2016 at 1:05 PM

"in TrueCrypt there was no noticeable delay. In VeraCrypt the delay is very noticeable and very annoying."

I think it's because of increased number of iterations for key derivation algorithm. In other words, if you're trying to decrypt just one partition/drive, the delay will be only slightly longer, but if you're trying the cached password against multiple drives, you will surely notice the difference.

For details see here: https://veracrypt.codeplex.com/discussions/569777

RealityExists wrote Jan 14, 2016 at 10:42 PM

I agree, that's very likely the reason.

RealityExists wrote Mar 3, 2016 at 9:32 PM

It's a bit faster in 1.17, but still annoying. Please, please fix this!