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

Slow volume mounting / the new PIN feature is silly

Topics: Feature Requests, Technical Issues
Jun 7, 2015 at 9:48 AM
I see that there has been a lot of discussion already about the slow volume mounting issue of VeraCrypt. I don't use system volumes, but the slowness is still an issue for me, even if I'm using a reasonably fast 3 GHz i5 processor and the latest stable (1.0f-2) that claims 'mounting speed improvement, up to 20% quicker on 64-bit'. So I decided to try out the 1.12-beta with the PIN feature (lower iteration count for faster mounting) and I still feel disappointed.

First of all, let's think this from a normal end user perspective. In order 'to get rid of the slowness', you are asking that the user specifies a PIN for the volume, essentially a second short password (even if it's just a count number, the user still has to remember it). So, the password dialog asks for two passwords, that fact alone doesn't make any sense! If you put the feature in the final release, you might get requests like "Can I just use my PIN and save the real password securely on the system?" (so essentially similar how Bitlocker works for the user on his corporate laptop..)

Secondly I think I found a bug in it: AFAIK I had to use Change volume password feature to start using the PIN, so I "changed" it by setting the same (very long and secure) password again and set the PIN to 1. I have two favorite volumes that are automatically mounted at logon, so I did this for both. Now it looks like the first volume mounts fast, but the second one is as slow as previously and it even asks the password again (password caching doesn't work anymore).
Jun 7, 2015 at 11:11 AM
Version 1.0f-2 introduced an optimized key derivation function that effectively reduces mounting times and the 20% figure was calculated using SHA-512 on a 64-bit platform.

The whole point of VeraCrypt is to have a transparent development process, open towards the community of its users. As one might expect, this sometimes leads to heated exchanges, criticism or even insults but I decided to maintain this way of work because at the end it will benefit everybody.

Thank you for sharing your opinion in the new PIN feature. Indeed, this value can be seen as a secondary password and some would be tempted to abuse it, but one has to take into account all aspects, not only potential negative ones.
The idea behind the PIN is add a new security dimension to VeraCrypt security model that was solely based on a fixed number of iterations with variable length password. This new dimension enables a flexible adjustment of performance/security tradeoff.

In this prospect, do you have a better idea than the current one or any proposal for implementing it better? Are you in the camp of those against a dynamic security model? You are encouraged to propose alternative solutions.

Concerning the favorites issue, as indicated in the release notes, an option was added to temporary cache password when mounting multiple favorites. In the previous versions, the mounting multiple favorites at the same time, VeraCrypt automatically tried to open a favorite on the list using the previous successful password: this was OK for those using the same password for all favorites but for the others who don't this was penalizing as they had to wait for the failure before having the password prompt.
Since you are using the same password for all favorites, you can activate the temporary caching by going to Settings -> Preferences and checking the option "Temporary cache password during "Mount Favorite Volumes" operations.

Thank you for sharing your feedback and your thoughts.
Jun 7, 2015 at 1:06 PM
Thanks, I'm sorry if I was a bit blunt in the first message. I really appreciate that someone has picked up the ball after Truecrypt dropped it. I'm just an end user, but I followed the discussion briefly after Truecrypt's announcement, it's great that you take real action instead of mulling about the license, features and security.

I actually had that 'Temporary Cache password during "Mount Favorite Volumes" operations' on, and also 'Cache passwords in driver memory' and 'Wipe cached passwords on exit' were on (because I set the prefs to be similar that I have in Truecrypt). But now that I wanted to test the issue further, I can't reproduce the slowness anymore. Mounting the volumes is fast and it also remembers the password. Maybe it was some glitch with the upgrade from 1.0f-2 (I did a reboot..), or because I actually changed the mounted volume content after setting the PIN? Anyway, I'll see if the issue reappears.

As for proposals, what about borrowing one from KeePass: a button that calculates a 1 second delay on this computer, and sets the iteration count to a new volume according to that? Mounting would still be slow if the volume is on a USB stick and used on different computers, but you could give an instruction to set it on the slowest machine the volume will be used on. These days, CPU performance differs so much between devices, so you would also essentially suggest a somewhat 'random' PIN for the user, instead of just putting '1' there like I did :-)

As I'm not a security expert and not even a coder, I can't say if a new security model is really needed. I remember that the low iteration count was one problem mentioned in the Truecrypt security audit? It's great that you are addressing it, but the cost to usability should be as low as possible.
Jun 7, 2015 at 2:09 PM
Edited Jun 7, 2015 at 3:50 PM
Hello MT76,

You make a good point about people mistaking the Volume PIN as a secondary password instead of the number is a multiplier to the iteration formula for the header key.

There are discussions in the ticket in the link below for different approaches and naming suggestions for the new field.

Can you provide alternative name to the iteration multiplier field which in the beta release is called Volume PIN? Or perhaps suggest another approach to make the field more user friendly?

Thank you!
Jun 7, 2015 at 4:37 PM
Why not call it what it is? e.g. Volume iteraction multiplier or VIM - That will not be mistaken as a "second" password..
Jun 7, 2015 at 5:32 PM
Edited Jun 7, 2015 at 5:49 PM
destrukt wrote:
Why not call it what it is? e.g. Volume iteraction multiplier or VIM - That will not be mistaken as a "second" password..
Great suggestion! I like the idea! Did you mean iteration instead of i[n]teraction? Maybe "Header Key VIM" or "Header Key Iteration Multiplier" to avoid non-technical user confusion with the encryption key? My preference is to avoid a new unfamiliar acronym to try to make the GUI more user friendly.

One concern discussed in the ticket link I posted above is that non-technical users will not understand the meaning of header key iteration and the impact to security and mount times. Hence one idea is to have both a field and a slider.

However, this new field may just require the user to learn about the purpose and impact from the documentation as part of using the application.

The discussion in the other thread was trying to find a user friendly name.
Jun 7, 2015 at 7:22 PM
The whole point is to find a name that:
  • reflects the function of this field
  • indicates to the user that it is something that is personal to his and that it must be remembered
  • avoids technical terms that may be too complicated for the average user
Taking those three points as a basis, the words "Key" or "Header" don't seem to fit.
"Multiplier" is important and it is simple to understand.
"Iterations" is technical but it can be easily understood.
From here, I would like to use the word "Personal" since it reflects that this value is specific to the user and it will be easier to explain that it must be remembered. This would lead to "Personal Iterations Multiplier" or PIM.

Another alternative is to use "Custom" as proposed by Enigma2Illusion previously. This would give "Custom Iterations Multiplier" or CIM.

In the GUI, I prefer to avoid long sentences for the fields names, that's why acronyms are used. As this point, the fields can be named:
  • Volume PIM
  • Volume CIM
and the documentation will explain the meaning of the acronyms (PIM or CIM).
Jun 7, 2015 at 9:24 PM
Volume PIM and Volume CIM are certainly better than Volume PIN. Adding a new acronym to the program is unfortunate, but I guess it can't be avoided. Just using simple words can be misleading or misunderstood.

The slider helps teaching users the concept, but maybe I would dedicate a separate page in the volume creation wizard for that (more room for explanations, both for the password itself and the multiplier).
Jun 9, 2015 at 12:15 AM
Two suggestions:
  • The Iteration Count should be saved (in the plain) in the volume header so the user does not need to enter it in, or even know it exists. Right now I need to explain the PIN to my end-users as such "The PIN code is a weird number you just need to enter in because VeraCrypt is sorta broken right now" which leads them to ask why we are even using VC to begin with (since it's broken).
  • VERY IMPORTANT: There should be no restriction on the Iteration Count. If I want an IC of just 3 then I should get it. I don't understand why you, the developer, who has no idea of how I run my IT department, gets to dictate to me what is and is not acceptable security. A decent password of length 8 and an IC of 2000 will never ever be broken by anyone other than extremely rich state actors, to which I say... WHO CARES. I do not care if the NSA see's our business data of a medium sized company. It is useless & un-interesting to them.
Jun 9, 2015 at 3:05 PM
Good points, brett. Why the iteration count should need to be such a prominent feature, bothering and confusing users in every password dialog? It could be saved to the header, and maybe even auto-calculated during volume creation like I suggested above. Then changing the iteration count could be an advanced feature hidden in some submenu.

AFAIK Truecrypt didn't prevent bad passwords, just warned about them. Iteration count should be free, but a warning is of course acceptable if the password&count combination is dangerously bad.
Jun 9, 2015 at 6:01 PM
Edited Jun 10, 2015 at 1:16 PM
Just to prevent future misunderstanding of the new Volume PIM field, the value you enter is a multiplier based on the conditions and formula below. Not the actual iteration value for the header key.

If a value is specified in PIM, then the iterations are calculated as follows:
  • For system encryption: Iterations = PIM x 2048
  • For non-system encryption and file containers: Iterations = 15000 + (PIM x 1000)
If the password is less than 20 characters, PIM must be greater than 98 for system encryption and greater than 485 for the other cases.
If the password is 20 or more characters, PIM can be equal to 1 and upwards.

TrueCrypt Audit Report on Header Key Derivation

Before we continue with this debate, let us review why the Header Key was an issue in the audit report. Here is a snippet summary from the TrueCrypt audit report.

The iteration count used by TrueCrypt is either 1000 or 2000, depending on the hash function and use case. In both cases, this iteration count is too small to prevent password guessing attacks for even moderately complex passwords.
So what exactly does that mean? The audit report stated:
EXPLOIT SCENARIO: An attacker captures an encrypted TrueCrypt volume and performs an offline brute-force and / or dictionary attack to identify the key used to encrypt the Volume Header. They use the recovered key to decrypt the volume.
There are two types of attacks. The password and the hash key.

There are yearly contests at DEF CON "Crack Me If You Can" and they have different divisions of hardware class and complexity. We are not taking NSA, just hacker teams.

The only point I am making is that weak total number of iterations derived from the low multiplier (Volume PIM) and weak password can led to common thieves getting access to your data. That is why VeraCrypt allows adjusting down the multiplier when password is 20 or more characters and VeraCrypt prompts you asking that you used a strong password.

I don't understand why you, the developer, who has no idea of how I run my IT department, gets to dictate to me what is and is not acceptable security.
This is rehashing a very long and heated debate that took place about 7 or 8 months ago. There were people for/against even allowing lower values. Not even discussing the actual values. :-)

Mounir understands very well the types of security threats available of off-the-shelve hardware/software and working with other professionals in the Crypto field to develop these "rules" to protect your data and to maintain the high security of VeraCrypt just as TrueCrypt had earned its exalted reputation until it became outdated due to lack of security enhancements.

AFAIK Truecrypt didn't prevent bad passwords, just warned about them. Iteration count should be free, but a warning is of course acceptable if the password&count combination is dangerously bad.
Unless a future release of VeraCrypt is planning to include a password entropy indicator which has been discussed recently, you make a good point.

Regarding storing the total iterations in the clear, Mounir has stated why he will not change storage format in the link below.
Jun 9, 2015 at 11:35 PM
Edited Jun 9, 2015 at 11:37 PM
Enigma2Illusion wrote:
Regarding storing the total iterations in the clear, Mounir has stated why he will not change storage format in the link below.
This problem can easily be solved by generating a random number that modulo 1001 would give the IC multiplier needed to mount the volume. Here's a simple algorithm for hiding the user-selectable IC multiplier inside a randomly generated 32-bit number:

uint32_t G = 1001;
uint32_t M = 90;  // User requested PIM (valid range: 1 - G)

    uint32_t R = genrand64_int64();
    uint32_t B = R - ((R % G) - M); // Hide the PIM inside a random number
    printf("B = %08X :: B mod %d = %d\n", B, G, B % G);
Sample output:

B = B4A22E66 :: B mod 1001 = 90
B = EB22E2F1 :: B mod 1001 = 90
B = 234C8A5D :: B mod 1001 = 90
B = E8C5359B :: B mod 1001 = 90
B = 26C71806 :: B mod 1001 = 90
B = 7BFDF27C :: B mod 1001 = 90
B = 382AD658 :: B mod 1001 = 90
B = F2FA89B3 :: B mod 1001 = 90
B = A457ADC9 :: B mod 1001 = 90
B = 8BFDCE2A :: B mod 1001 = 90
B = 2FFD9AFB :: B mod 1001 = 90
B = D9242C2D :: B mod 1001 = 90
B = 538B036D :: B mod 1001 = 90
B = 2F28A795 :: B mod 1001 = 90
B = 344A601F :: B mod 1001 = 90
B = CD89CC45 :: B mod 1001 = 90
B = 5E9FC160 :: B mod 1001 = 90
B = 6D7108DC :: B mod 1001 = 90
B = E683E957 :: B mod 1001 = 90
B = 22AA6BF7 :: B mod 1001 = 90
Jul 14, 2015 at 12:41 PM
There seem to be two main issues here. One with the terminology used which can clearly be confusing to someone as PIN carries a specific understanding to most humans as (Personal Identification Number e.g Password) whereas in this case it is simply a Volume iteration strength of sorts. So perhaps it should be "VIS:" and if that is for some reason too confusing it can be clarified elsewhere as to what that is. Perhaps have a little blurb on the side that says "If you don't know what this is just leave it empty" which is a pretty fair assessment one would think.

I also agree with Brett, minus the sass that the product should not actually inhibit or stop a person doing something silly such as low iterations provided it doesn't harm their data. Perhaps have a threshold at which if the user selects anything below x it pops up one of those lovely warning popups that TC/VC do to warn you that you are drastically reducing your encryption strength.
Jul 14, 2015 at 1:12 PM
There have been many changes to this feature (now called PIM). most notably, it is now offered to the end user only when a specific check box is ticked (much like keyfiles). Also, there is a warning when the iteration level is reduced.

Can you please test the new 1.12-BETA and give your feedback about it? It is available here:

Also the documentation has been updated to include this. Any feedback on it will be welcomed (for example and
Jul 29, 2015 at 12:16 AM
I have been using this at home for awhile (at work I have now reverted everyone back to TrueCrypt as the performance is significantly faster (<1 second boot up time versus 120 second). I am still wondering why the PIM cannot be stored in the volume header using stenography (mentioned above & in another thread I started). There is no statistical analysis that can differentiate a random number from other equally random numbers, and even though the source code is public, knowing the modular divider does not help any. Proof:

Which of these below 32-bit random numbers are my personal PIM and which are not. The source code specifies the modular divisor will be 50, and that the result will be incremented by 1 then multiplied by 10,000. Thus the smallest resulting iteration count is 10,000 and the largest is 500,000:

28C05EFA = 17k iterations
A799982C = 37k iterations
95484256 = 9k iterations
5F6FCBCA = 37k iterations
FEA57415 = 22k iterations
49CBB98C = 27k iterations
050098D6 = 7k iterations
07167EED = 48k iterations
9D5973CA = 9k iterations
1B5A1BDB = 4k iterations

So tell me which of the above 10 numbers found in the plaintext "header" of the volume are my selected PIM's and which one's are just random data found on a random drive?

It's impossible. A person could realistically choose 10k iterations and as many as 500k, thus knowing the source code and knowing where the data is stored is useless. No one can prove the difference between a randomly generated file and a VC volume using this location. It's just random. System Volumes already contain megabytes worth of unencrypted data and are easily detected as VC volumes, so storing the PIM in plain-text provides no security risk at all.