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

Way too slow to mount a simple volume

Topics: Technical Issues, Users Discussion
Nov 17, 2015 at 3:05 PM
I created a VeraCrypt volume of 10Gb with a simple 10 digit pass AES.
Running on i7 with 8Gb RAM, windows 7 x64. It takes unacceptable 20 seconds to mount.
This is a bug or something? I rather use TrueCrypt than wait 20 seconds to get a volume mounted.
Is there plans to fix that in future version or it will always that that long to mount?
Nov 17, 2015 at 3:21 PM

You can search the forums here or on Sourceforge and you will find your answer.

The PIM feature was introduced for those using strong password and who don't need high iterations:

For your information, on a Core-i7 2600K CPU @ 3.40 GHz running Windows 7 64-bit, the mounting times are indicated below (this is the output of the file bench.bat found on Git inside the "Test" folder and which can be accessed here):
SHA-512 (Normal) = 00:00:03,45
SHA-512 (Hidden) = 00:00:06,84

Whirlpool (Normal) = 00:00:06,78
Whirlpool (Hidden) = 00:00:13,49

SHA-256 (Normal) = 00:00:05,04
SHA-256 (Hidden) = 00:00:10,19

RIPEMD-160 (Normal) = 00:00:10,67
RIPEMD-160 (Hidden) = 00:00:21,36

Wrong Password (PRF Auto-detection)= 00:00:21,61
Times are in seconds.

You can download a zip with all test files from

You can post here the output of bench.bat alongside your CPU reference to have a comparison.
Nov 17, 2015 at 4:54 PM
Edited Nov 17, 2015 at 4:55 PM

I set the PIM to 1 and it mount instantly with 43 length pass. (I don't want to keep another thing (PIM) to remember besides the password itself, so I set PIM to 1)
However I got this message when creating the volume:

So, does that mean my volume is weakly protected and can easily be brute-force attacked?
Nov 17, 2015 at 5:16 PM
As indicated in the message, "if your password is not strong enough, this could lead to weaker security".
A long password is not necessary strong, so this message is displayed to inform the user that it is his responsibility to ensure the strength of the password.

If the user keeps the default VeraCrypt PIM value, the high number of iterations is a deterrent against any brute force attack. of course, this adds an extra delay in mounting without any impact to read/write operations.

For users who have sensitive information and who need optimum security, a dozen seconds more to wait for mounting is a negligible cost for the extra security. For the other casual users who don't need this security, a small PIM is a good compromise provided that the password is strong enough.
Nov 17, 2015 at 6:35 PM
Thanks for the explanations idrassi!

Just out of curiosity: a password with a length of 20 composed by 0-9, a-z and special chars (#$@_! ...)

How long would take to a power computer to find the password considering PIM = 1?
Nov 17, 2015 at 7:17 PM
Correct me if I am wrong, the number of iterations using PIM is used to slow down the attack of the password or hash value of the header key.

Mounir has posted on the topic of password length and its entropy that would be worth reading.
Nov 18, 2015 at 6:34 PM
Edited Nov 18, 2015 at 6:37 PM
Enigma2Illusion wrote:
Correct me if I am wrong, the number of iterations using PIM is used to slow down the attack of the password or hash value of the header key.

Mounir has posted on the topic of password length and its entropy that would be worth reading.
Mounir's post is only partially correct. Or, rather, it is only correct if you make certain assumptions. His post essentially says the more types of characters you have in your password, the entropy your password has per character. This makes the assumption that in any position in the password, there is an equally likely chance of having it be an upper case letter, lower case letter, number, or symbol. The problem is that this is almost always not the case. A truly random string of upper/lower/number/symbols that is long enough to be useful is almost impossible to remember. So, to make passwords easier to remember, people generally sprinkle in numbers and symbols in certain spots. For example, letters are urually ganged together. You can't assume that as soon as you drop in one or two symbols in a 20 character password that your entropy per character is increasing greatly.

Here are some rules of thumb for password entropies in scenarios people often use to pick passwords:
  • 1.2 bits of entropy per character when that character is a letter that is part of a word in any language. This is approximate and drops with the length of the word.
  • 1.2 bits of entropy per character when that character is a part of a string representing a certain letter in a known phrase. IE: last letter of every word of a line from a nursery rhyme
  • 2.6 bits of entropy per character when that caracter is is a part of a string representing a certain letter in an phrase not knowable to anyone else. IE: you make up a little ditty rhyme and use the 2nd character of every word.
  • 5 bits of one-time entropy for a truly random number or symbol added at a natural break (ie: at the end of a word, end of a portion of a phrase, or end of the password itself)
  • 5 bits of one-time entropy plus a bonus of about .1 bits of entropy per character for a truly random character inserted at a truly random position inside a password. The addeed per-character entropy stacks if this is done multiple times but only to a point, and only if every added character is in a truly random position, and not (say) grouped together or every nth character.
I also recommend that you never, ever depend on password strengthening. Always assume that the feature doesn't work and pick a password that has entropy equal to the strength of cipher you are using. The reason for this, is that it has never been proven for any hash that VC uses that it is hard to get the nth iteration. Hashes are designed to be reliably diverse, in that a small change in the message produces a large change in the has. Cryptographic hashes are designed to be difficult to reverse, in that it is difficult to get the message from the hash. Neither of these means that to get the 1000th iteration of a hash that you have to do all of hashes 1 through 999. In the same way, it has never been proven that chaining together ciphers gives you any added security. There may be subtle ways that a hash of a hash of a hash (repeat a thousand times) operates that make it easy to get the thousandth hash. Use for password strengthening was not a criteria in the design of any of VC's hashes. So do not depend on it to make your password safer.

It is likely that iterating the hashes increases the difficulty, and the concept of password strengthening is a good idea (in fact I opposed even adding the option to reduce the iteration count) but no one should depend on it. And never ever depend on increasing PIM to make a weaker password stronger. Pick a password with entropy equal to the cipher strength, then let password strengthening be what it is, which is added forward security in the best case, and something that likely does no harm in the worst case.
Nov 21, 2015 at 2:58 PM
Edited Nov 21, 2015 at 3:11 PM
Hi all,

I too had noticed that the time to mount a container was much slower than TrueCrypt.
I assumed it was due to some change or the other in VeraCrypt was causing it, but since I love VeraCrypt in just about every way, I put up with it. I've now learned in this thread, it IS caused by VeraCrypt code but it's by design, in a way. I have read through the manual but evidently not enough or I would have known the PIM could be set to 1 to negate the wait.

For what it's worth, here are my results from running bench.bat:

Intel Pentium G3258 3.20GHz OC to 4.20GHz
8GB 1600 RAM
Windows 10 Pro x64
SHA-512 (Normal) = 00:00:02,30
SHA-512 (Hidden) = 00:00:04,56

Whirlpool (Normal) = 00:00:04,91
Whirlpool (Hidden) = 00:00:09,78

SHA-256 (Normal) = 00:00:03,43
SHA-256 (Hidden) = 00:00:06,72

RIPEMD-160 (Normal) = 00:00:08,35
RIPEMD-160 (Hidden) = 00:00:16,74

Wrong Password (PRF Auto-detection)= 00:00:26,64

Press any key to continue . . .
So as you can see, there is no time that's completely unacceptable, it's just that people were spoiled by TrueCrypt mounting a container almost instantly.

BTW, I had to add a 'pause' ("Press any key to continue...") in another batch file to get the command prompt window to stay open to view the results. I simply called batch.bat, placed 'pause' below it and it stays open.

Why would someone write that bench.bat that closes upon end of execution? Well, no matter.