long boot time

[Anonymous]

Hello.
First thank you for continuing this project after the strange Truecrypt end.
I have a SONY VAIO laptop using now "Veracrypt 1.04d" instead of "Truecrypt 7.1".
I works well except that after input my password, it takes one minute to start booting Windows7 64bits.

Can you please help me to improve this delay ?
Thanks in advance.
F Malaterre

[Mounir IDRASSI]

Hi,

This delay is caused in part by the fact that we increased the iterations count to a level that gives us the best possible security while still being useable.
Another reason is that the encrypted partition doesn't contain any indication about the encryption algorithm for security reasons. So, in order to boot Windows, VeraCrypt tries all available encryption algorithms in sequential order (AES -> SERPENT -> TWOFISH -> TWOFISH+AES -> SERPENT+TWOFISH+AES -> AES+SERPENT -> AES+TWOFISH+SERPENT -> SERPENT+TWOFISH). Thus, if you choose an encryption algorithm that is in the middle if the list (for example AES+SERPENT), you will wait more time than if you choose AES only.

For that point, we are thinking about adding an entry in the boot menu to let the user select the correct encryption algorithm so that we can save time.

Last point : the code of VeraCrypt BIOS boot loader runs in a restricted environment with limited resources and legacy mode (16-bit), which make all cryptographic computation slower. Once Windows is started, we go back to normal more with no performance degradation.
We can do nothing about this. In the future, we plan to support UEFI boot which enables the use of more resources for booting.

As a summary, we can optimize only the case where an encryption algorithm other than AES is used by enabling the user to select the correct encryption algorithm directly instead of trying all combinations. If tests are OK, this could be included in the next release.

[Anonymous]

FYI... I chose AES, and just encrypted a 12 gig partition on the drive, NOT a system boot partition and it too takes noticeably longer to mount than with Truecrypt. BUT once mounted the files seem to process just as fast as Truecrypt's last version. I am going to start a second thread about some behaviors I have noticed.
-Sir.Roberte

[Mounir IDRASSI]

Thanks for this feedback.
Yes, the mount of a volume under VeraCrypt is slower than TrueCrypt because of the enhanced security of key derivation as explained in my post. As you pointed out, once mounted, read/write operations have the same performance as for TrueCrypt.

[Anonymous]

Everyone commenting on the slow speed, or how much longer VeraCrypt takes to open a container should actually see this as a positive !!! The longer it takes the genuine user to open the container with the correct password the better, just imagine how much harder it will be for the attacker !

Users just don't seem yo understand the benefits of this, which is disappointing.

[Anonymous]

Anything that degrades the performance of a pc is not a "Positive"

[Anonymous]

hi

[Anonymous]

Hello,

I had use the true crypt software but after stop service we have try vera crypt both installation as same as per my observation. i have getting issue when i insert password while booting it will take 40 sec to accept the password any idea how to decrease time or any option for fast booting. please reply

Thanks in advance

[Mounir IDRASSI]

Hi,

For those who prefer to have a fast boot, we are currently implementing a security level choice where the user can choose to have strong, medium or low security.
The low security mode will be the fastest and at the sametime it will be stronger than TrueCrypt (10000 instead of 1000).

We'll release a beta version that includes this feature soon, so stay tuned.

[Anonymous]

Has this vesrion been released yet??

[Mounir IDRASSI]

No and we don't think that this feature is going to be included after all. We had some exchanges about it with different users and it appears that it will add confusion about the real security level of VeraCrypt and it will also be a big departure from the spirit of TrueCrypt were all created volumes are assured of having the same level of security.

Moreover, as I always repeat, this delay affects only the boot time and not the performance once Windows is loaded, so it is worth waiting if you have really sensitive data that need this level of security.

A more important feature is to rewrite the bootloader in order to evade the limitation of the current 16-bit mode that makes the performance of the boot so poor. Once we have a 32-bit bootloader, the boot time will dramatically decrease without a need for decreasing the security of the encryption.

[Anonymous]

"we don't think that this feature is going to be included after all"

AWESOME !!! :)

I am really pleased to read that ! VeraCrypt is 100% security, no compromise :D

L0ck

[Anonymous]

If the delay is too long on older systems and users have no alternative, one might argue they may not use it at all. While 'confusing the user' is one reason for omitting, it is certainly no more complex than remembering which keyfiles were used to protect a non-boot volume. If the choice of selecting hashing iteration levels at boot is added, adding a 4th paranoid level using 2x-5x more iterations than the high security level(and resulting in an even longer hashing delay) is equally attractive.

[Anonymous]

Hello, could you please implement this to give the user the option to boot faster. I have a relatively fast CPU 3700K OC 4.2Ghz, but authentication at boot up still takes up to 30 seconds. I have already spent days encrypting a few large volumes with veracrypt, and it will cost too much time to revert to truecrypt. Or at least please release a "sideline" version with this function.

[Anonymous]

Seriously, if 30 seconds is too much to ask then you have no need for this security product.

Your threat model is simply not significant enough.

[Mounir IDRASSI]

I understand that for TrueCrypt users, booting using VeraCrypt would seem like an eternity but you can't have a fast boot and a good security level.

As I explained in different posts, reducing the key derivation complexity to make it as fast as in TrueCrypt is not the good answer. The objective of VeraCrypt is guarantee a minimal security level for the next 10 years and the key derivation complexity was chosen with that respect.

The real solution is to rewrite of the bootloader in order to switch to full 32-bit performance which will divide the boot time by a 2 or 3. This is part of the roadmap and it is the next objective of VeraCrypt.

I receive numerous request asking for the release of a version with faster boot (e.g. lower security) but I'm still not convinced if it is good on the long run.

Things may change in the future if I have or I received better ideas on how to implement such "security customization" without affecting VeraCrypt security targets.

[Stephen Brinich]

I've noticed a major improvement in mount time with 1.0fBETA3; thanks.

[Mounir IDRASSI]

Thank you Stephen for this feedback and for your support.
Happy new year, wish you all the best.

[Anonymous]

Ignore the detractors Mounir, aim for security only. People such as those above who need speed not security can use a less secure product, keep VeraCrypt for those who need real security.

Personally I think the full 32bit performance should perhaps be number 1 on your "to do" list :)

It will stop a lot of threads like this one.

[Anonymous]

Agreed. Ignore the detractors. You just never know who might be offering this type of advice/suggestion.

-EOM

[Anonymous]

Please implement fast boot, I don't see any problem at all. People beeing confused of this function are too "confused" to use a secure password. Nobody would be confused at all.

As long as people can choose to use a high iteration then there is no problem. And no, I don't come from the NSA, I come from planet usability and with Windows I have to reboot a lot of times and was so happy that after my SSD and Windows 8.1 I can boot up in less than 15 seconds and now this problem comes up...

Let the people be free in their choice, freedom is dangerous but when giving up freedom for security you will loose both in th eend (probably not the wisest quote to use in this context, but it sounds cool and makes sense in the political context).

[Anonymous]

Hey, you have to implement an option to use lower iteration, it can be still higher than TC but every user should be able to decide himself if he wants to get high bruteforce security or low bruteforce security, although the length of the password can completely eradicate the need of high iterations... so pleaaaaaaaase give us this feature!

At this point Veracrypt is unusable for my system partition which is really sad! Let the users decide if they want high iterations or not!

[Anonymous]

"although the length of the password can completely eradicate the need of high iterations"

This is not necessarily true, your use of the word "can" saved you from ridicule.

[Anonymous]

So why do you think it is wrong? When you have a 64 character password then there is no need for high iterations, cause bruteforcing even in realtime would take hundred of years and that includes progress in technology that we are able to foresee. It is more likely that AES 256 Bit can be defeated than the password...

So, I have nothing against high iterations but please, dear Mounir, implement the option of a lower iteration count like 10.000, that is still 10 times higher than the TC count! There are NO disadvantages of giving us this feature!

[Anonymous]

It is wrong because most users are not aware of what a good password is.

Length is not a guarantee of strength. Some unskilled users think quotes, poems and song lyrics are good long passwords, they would certainly meet your criteria for length.

However crackers already have very large dictionaries which contain these lines. Rules are used to manipulate leet characters and add dates etc.

So as you can see, there is actually a very serious disadvantage to reducing iterations. VeraCrypt needs to protect some users from themselves.

A good rule to consider when talking about encryption is, if you think you are secure, you have overlooked something. :)

[Anonymous]

Please cut the iteration count by 3/4. Even though this makes it 4x "weaker" in some peoples eyes, since computers double in power every 18 months, one would only have to wait 3 years to attack the iteration for the same level of success. Security does not come from high iteration counts, rather strong passwords. A high iteration count is just voodoo security, it's fake, and only idiots believe in it. But for us end-users, we can boot our computers in 15 seconds rather than 60.

[Anonymous]

It is users such as yourself the minimum iteration count is there to protect, you have no idea about encryption or how it works.

VeraCrypt is not a toy, it is REAL security. Try TrueCrypt or CipherShed instead.

[Anonymous]

"since computers double in power every 18 months, one would only have to wait 3 years to attack the iteration for the same level of success."

You have just made the case for higher iterations.

"Security does not come from high iteration counts"

You need to read what they do and why they are important.

"A high iteration count is just voodoo security, it's fake, and only idiots believe in it."

You are just trolling now. There are only about 3 individual people making this request but they are disproportionally represented in the request section.

"But for us end-users, we can boot our computers in 15 seconds rather than 60."

A clear case of choosing speed over security, VeraCrypt is not the appropriate encryption software for you.

I suggest you read and learn from this thread.

https://veracrypt.codeplex.com/discussions/577023

[Mounir IDRASSI]

Their will be a configuration option to configure the iterations count, although I'm envisioning two builds of VeraCrypt that shares the same code but only differs by the minimal value of the lower bound of the iterations. The difference will apply only to the creation of the volumes ("VeraCrypt Format.exe") and it will not affect the bootloader or the mount tool "VeraCrypt.exe") which will be the same.

• In the "full" build which will have the name "VeraCrypt", the lower bound of the iterations can't be lower than the current used value which means that we can only increase the value.
• In the "lite" build which will probably have the name "VeraCrypt Lite" (not sure yet about the naming), the lower bound of the iterations can be set to a much lower value depending on the password length (e.i. around 30000 for long passwords).

Anyway, once the code that handles dynamic iterations is implemented, it will be just a matter of #ifdef to separate the two versions. This way, it will much easier to maintain.

Of course, there is another opinion who asks for a simple switch or an option in the configuration file that will activate the mode where the lower bound value is smaller. Personally, I would like to keep the assurance that volumes created by the "full" build of VeraCrypt will have a high iterations count for those who need this. Technically speaking, volumes created by any of the two builds will have the same format and they can be mounted by any of the builds, but by separating the builds, those who will deploy the "full" build in an organization for example will have the assurance that all volumes created will meet a minimal security requirement.

[Anonymous]

Hey Mounir,

thanks for that!

Still I don't understand the logic behind your decision and I gave not up the fight hehehe...

When saying that there is the danger of users not knowing what the iteration count is and setting it accidentally too low (or simply they don't trust their own decision and want to "have the assurance that all volumes created will meet a minimal security requirement"), then there is the same possibility that they will use the "lite version" and do the same mistake or do other mistakes that are way more critical! Sorry, but these users would be really dumb and more likely to write their password down on a note at the fridge...

Also the iteration count is not anywhere as important as a strong password, that noob users are 10 times more likely to use... so I think it would be more useful to only create ONE version of Verycrypt that is able to set the iterations to 10.000 OR higher BUT in the process of creating such a volume the user gets a big fat warning that he has to click "okay".

I don't like the idea of having two versions of verycrypt, it is dividing the trust in it because now people had to compile TWO versions of the sourcecode to see if the .exes are true to the source.

So until you will be able to rewrite the bootloader to 32bit performance that would be the perfect solution, let the user decide and for the dumb users there is a huge warning. Hey, 10.000 iterations is still 10 times more than TC!

Don't split Verycrypt into two versions...

[Anonymous]

The separate Lite version is to protect the VeraCrypt name. Users who do not understand security will chose the Lite version for speed not security.

This leaves VeraCrypt full for REAL protection against a serious threat model.

10 times better than TC when TC was built many years ago does not even keep up with the rate of cracking power by adversaries.

Personally I would prefer all the people interested in speed over security to use CipherShed as I understand they may provide a weak iteration count to satisfy users with no threat model.

This discussion has been beaten to death many times, please do some basic research before reposting.

[Anonymous]

The logic is completely flawed. Veracrypt does not get weaker when it offers the possibility to use lower iterations. That is simply not true.

With that logic VC is not secure because it offers the possibility of a 1 character password. But that is just not true.

Why do people who don't need something want to take the liberty of other people away that need it when they can simply ignore it and use the higher iterations?

Do you fear that you can not trust your mind when encrypting a volume? Then check the volume details every day to see if you used SHA 512, a long password and high iterations... the problem is with YOU when you don't trust yourself and not the software that offers more possibilities.

And the name Verycrypt with your logic is damaged, too, because of the 1 character password. But it isn't. It's just an option.

Give me some logical ARGUMENTS and we can discuss.

[Anonymous]

Beating to death at this thread:

http://veracrypt.codeplex.com/discussions/577023

[Anonymous]

Most people are on the side to let the user decide if he wants high or low iterations. The software does not get insecure by letting the user decide.

[Anonymous]

"since computers double in power every 18 months, one would only have to wait 3 years to attack the iteration for the same level of success."

You have just made the case for higher iterations.

"Security does not come from high iteration counts"

You need to read what they do and why they are important.

"A high iteration count is just voodoo security, it's fake, and only idiots believe in it."

You are just trolling now. There are only about 3 individual people making this request but they are disproportionally represented in the request section.

"But for us end-users, we can boot our computers in 15 seconds rather than 60."

A clear case of choosing speed over security, VeraCrypt is not the appropriate encryption software for you.

I suggest you read and learn from this thread.

https://veracrypt.codeplex.com/discussions/577023

[Anonymous]

Veracrypt does not get weaker when it offers the possibility to use lower iterations. That is simply not true.

You need to study brute force protection.

With that logic VC is not secure because it offers the possibility of a 1 character password.

There are reasons the lower limit is available, it is used for other things.

Why do people who don't need something want to take the liberty of other people away that need it

Likewise LOL

Give me some logical ARGUMENTS and we can discuss.

People more intelligent than yourself attempted to argue this case, they were defeated in the link above.

VeraCypt is too secure for your needs, choose a weaker product.

Like the title says....

Open source disk encryption with strong security for the Paranoid

You clearly do not face a threat model significant enough to induce paranoia, use CipherShed or Bitlocker.

[Anonymous]

read this tweet from Veracrypt's official Twitter account. 

https://twitter.com/VeraCrypt_IDRIX/status/555283740394782720?s=01

I created a new VC volume and selected SHA-256 as hash and the mount speed was faster, about 50% faster. I suggest using SHA-256 if you want it fast and secure. 

This way there's NO NEED to reduce iterations and at the same time we're all using the same and only full version of Veracrypt and not making Mounir Idrassi create a fork of a fork. 

Maybe it would be a good solution and if explained well so that people who can't wait uses it, would reduce complaints and 'the need' for another version. I prefer one full version with complete and inmediate suport than two. 

I also want to say thanks to Mounir for dedicating so much time and efforts on this project. It's a better reality now, a guy that's continously working on it, that answers back, that accepts suggestion, that we all know. We did not have this with the people that developed Truecrypt so let's not abuse of his time and resources. 

I don't know if there's a hash algorithm that would be safe and faster than SHA-256. If it exists, adding it and explaining it and telling people that it is faster would help. 

With ONE and only full version of Veracrypt.

Copy and paste from Codeplex forum.

[Anonymous]

"You need to study brute force protection."

First of all: stop thinking that you are god and everybody not beeing on the same side is dumb and unintelligent, okay? If you are that arrogant all the time nobody wants to discuss with you and honestly that is a shitty way of talking to other people, be polite! Thank you!

My statement "Veracrypt does not get weaker when it offers the possibility to use lower iterations." is completely true when you are able to understand it correctly and don't try to understand it wrong.

"There are reasons the lower limit is available, it is used for other things."

Ooooooh, and I thought that you should not make ANY compromise with security? You are a hyprocite! Decide for one side! Eat this: There are reasons the lower iteration option is availabe, it is used for people that have a strong password but need fast access to their laptop when doing business work.

""Why do people who don't need something want to take the liberty of other people away that need it"

Likewise LOL"

I don't want to take the option away to use higher iterations...

"People more intelligent than yourself attempted to argue this case, they were defeated in the link above."

Simply rude.

"VeraCypt is too secure for your needs, choose a weaker product."

And you think when you repeat these "wise" words you are doing anybody a favor? There are thousands of reasons why it makes more sense to use Veracrypt instead of other products although you want to use lower iterations.

"You clearly do not face a threat model significant enough to induce paranoia, use CipherShed or Bitlocker."

Don't tell me what to do, thank you very much! But I guess I am not intelligent enough to talk with you, it is funny you say that there are only 3 people requesting the lower iteration feature when there are at max 2 people trying to avoid this feature in the sourceforge forum. One of them is L0ck which I guess is you...

My guess is that over 70 percent of the Veracrypt users right now wishes the options for lower iterations. Again my question: can you give me LOGICAL arguments against such an option? You did not give me any...

The only reason against lower iteration options I could think of and found in the other discussion is the following:

1. Dumb people could accidentally (after 3 big fat warnings you have to click okay) use lower iteration and think they are fortknox safe against bruteforce with a weak password.

2. The image of Veracrypt could be damaged. That is bullshit because then the 1 character password (does not matter if there is any need for them, in your logic just the option is unsafe) would damage the image even harder... also TC has 1000 iterations and VC would have at least 10.000 or 30.000 which is 10 to 30 times better than TC. You could also argue that even 500.000 iterations would be too less, cause "dont give up security for speed!!!!11111" and you want to wait 5 hours until you realize you typed the wrong 64 character password in...

3. Malware could change the iteration count in the background without the user knowing. Well, if that is the case the malware could also read the data, probably read out the password and do much more efficient attacks on the drive than this "attack".

4. More code is giving the possibility for more bugs and this makes the software less secure. Well, that is bullshit, too, with that mindset you could not give Veracrypt ANY feature at all and changing the iteration number and creating a little menu to change the option is such a small fraction of the code...

You see, I really try to understand you but when looking at the facts objectively of both sides I am still convinced that given the user the option of choosing the iteration count with a minimum of 10.000 or 30.000 iterations is not making the software any weaker but a lot more userfriendly for those that need it!

But in life we have to make compromises and the idea to create a static and dynamic mode for the iterations is great and I would like that very much! Please do that, Mounir, then eveybody (except close minded people) would be happy!

Oh and by the way: I would call myself paranoid, too, you do not want to know what security systems I have installed in my apartment... but these systems have a nice analogy to Veracrypt: to be able to get in my apartment within 10 seconds but still beeing relatively secure I can not allow to have 20 EVVA MCS locks at my 5 steel doors and a 10 minute safety waiting period to get it. That would be totally unpractical.

[Anonymous]

To be honest I am surprised your petulant foot-stamping and personal insults, including swearing, managed to get past the moderation.

You have just lost all credibility and are therefore irrelevant to this discussion.

Most of your figures are guesses and speculation. All your points were addressed and defeated in this thread. You have brought nothing new.

https://veracrypt.codeplex.com/discussions/577023

Creating new user names on the forum and constantly whimpering about the result here, will have no effect.

32bit bootloader will help to ease your impatience, I suggest you place equal effort into encouraging that feature implementation as you do to whining about the excellent brute force protection we currently enjoy.

But I guess I am not intelligent enough to talk with you

I accept your capitulation. You may be no wiser but you have certainly been better informed.

[Anonymous]

Are we in kindergarden now? I am insulting YOU?

"People more intelligent than yourself attempted to argue this case, they were defeated in the link above.

[...]

VeraCypt is too secure for your needs, choose a weaker product."

Instead of giving arguments you only come up with the same topic link I already completely read and conspiracy theories, I have not a single account on the other forums where veracrypt is discussed, so it is very likely that there are a lot of people out there that want less iterations and not only one person that creates douzens of accounts...

Is it so hard for you to repeat how you "defeated" all my points? Give me the short form, don't be lazy and flee from a discussion, I am open-minded and when your bring up good arguments I might change my mind!

We do not need a splitted veracrypt community! We need to stay together!

And when you accept the option of static and dynamic iterations like Mounir proposed then we already have a solution!

[Mounir IDRASSI]

Let's all go back to constructive exchanges and leave personal attacks and comments behind. I believe most of participants have good intentions towards VeraCrypt security and because of the strong positions of each, the heated debate may spin out of control. That's why I will delete any further posts that I deem non-constructive.

I want to reassure everybody that there is a place for everyone in the VeraCrypt community. Concerning the configuration capability asked for those who wish to speed things up, it will be available but as an extra download: either through a "VeraCrypt Lite" distribution or as an "addon" installable above the main VeraCrypt install and that will be clearly visible in the GUI.

Any thoughts about the new addon proposal?

[Anonymous]

The addon is a nice idea, seems better than "VeraCrypt Lite". I'd like to read more about those GUI changes, though.

Mrere

[Enigma2Illusion]

Mounir, I still prefer your original idea of Static Mode (which will be the default with the current iteration settings) and Dynamic Mode for user selection range to allow slower/faster mount times than the users having to download the addon.

I am proposing that the Dynamic Mode allow both lower and higher range values than the Static Mode.

I agree with you Mounir that having Static and Dynamic will not ruin VeraCrypt's security reputation no more than currently allowing a one character password with one warning message during the creation of volume or no password with one keyfile with no warning message during the volume creation has not damaged TrueCrypt's reputation as a strong encryption utility.

The user should have the various options based on their specific needs as to password length, keyfiles and Static or Dynamic Mode for iterations.

To me, the Dynamic Mode addon and VeraCrypt Lite proposals are unnecessary. Allow the user to select either Static or Dynamic.

Mounir, based on the heated discussion on both threads and participants pro/con to Dynamic Mode unable to reach a compromise on the various solutions will require you to make a decision that is guaranteed to not please everyone. Sometimes, you have to go with the idea that you think is the best approach.

What do you estimate the number of hours to complete each of the following?

1. Creating Static and Dynamic Modes (no addon, no VeraCrypt Lite)?
2. Creating VeraCrypt Lite?
3. Creating addon?
4. Creating 32-bit bootloader?
5. Creating 64-bit bootloader after the 32-bit bootloader has been released?

This would help the community prioritize the options based on the work effort. You have stated that the 32-bit bootloader will reduce the system volume mount duration by 2 or 3 times. For 64-bit OS's, will there be another reduction for system volume mount duration by 2 or 3 times over the 32-bit bootloader?

I want to thank you again Mounir for being open minded about these issues.

Edited to include VeraCrypt Lite as unnecessary.

[Anonymous]

Any thoughts about the new addon proposal?

Yes, I suggest you leave it until after the 32bit boot-loader has been created.

I doubt many but the most impatient user would mind the short delay in booting when the new boot-loader is installed.

Saving time not creating the weaker iteration Lite addon, will allow for more time to work on the new boot-loader which helps everyone.

"VeraCrypt Lite" distribution or as an "addon" installable above the main VeraCrypt install and that will be clearly visible in the GUI

If you are not going to create a clearly separate Lite version you need plenty of pop up windows and warnings. It is VeraCrypt's responsibility to warn the user they have weakened their protection and it is something not considered safe by VeraCrypt. If it was considered safe VeraCrypt would have had the same number TrueCrypt did, nothing has changed to justify an iteration drop, quite the contrary in fact.

You also need to consider malicious tampering, someone swapping the full VeraCrypt with a crippled Lite one. The 2 products need to be very distinctive, slipping in deliberate iteration weakening via an addon might become an attack option.

I was all for VeraCrypt Lite or addon a week ago, however the speed increases offered by the new boot-loader should remove the necessity for the Lite version altogether.

Don't forget, CipherShed will "hopefully" be released by then, Mrere can choose to employ it instead of VeraCrypt if the new boot loader does not meet his speed demands.

[Anonymous]

Is it so hard for you to repeat how you "defeated" all my points? Give me the short form, don't be lazy

You are clearly impatient by nature. You are 1 of possibly 2 or 3 people who complained about the boot time delay out of the thousands of users. You are also too impatient to read and understand the link provided.

I find it odd you take the time to troll the forum and sourceforge and yet you require immediate access to your drive.

I do not think we should be taking much note of requests by users such as yourself. Your priorities are not compatible with the main aims of VeraCrypt.

However, as the new boot-loader will provide a significant speed increase without weakening security, I suggest you give it a try when it is released.

[Anonymous]

To better identify my posts I will give myself a name now: Freeman.

I will be perfectly pleased when the 32bit bootloader is out there and then I don't see the need for lower iterations (as long as the boot time is under 20 seconds with good hardware and AES + SHA512 bit...)

But how long will it need for the new bootloader to be released? If it is more than one month I think the Addon will be the best solution. Make L0ck happy and display a big fat warning the user has to click okay when installing the addon.

What iterations will you use for the lowest setting then? 10.000? What about the idea of using a static and a dynamic mode?

OFFTOPIC: VeraCrypt does not officially support Windows 8.1, why? Will there be an option to convert TC system partitions to VC system partitions?

Freeman

[Mounir IDRASSI]

Hi Freeman,

Windows 8.1 is supported. Where did you see that it is no officially supported.
Converting TC system partitions can be tricking if the system is running since the TC driver is handling all read/write operations. Implementing the conversion in offline more is not always feasible. That's why I'm not going to implement this.

[Anonymous]

Enigma2Illusion

I agree with you Mounir that having Static and Dynamic will not ruin VeraCrypt's security reputation

I'm sorry, I can't find where Mounir said that.

However I did notice this....

Mounir

I would like to keep the assurance that volumes created by the "full" build of VeraCrypt will have a high iterations count for those who need this.

.....

Mounir

but by separating the builds, those who will deploy the "full" build in an organization for example will have the assurance that all volumes created will meet a minimal security requirement.

The quotes above seem to contradict Enigma2Illusion's claim.

The discussion has been over for some time on the forum, you and Mrere need to accept that. A conclusion was reached, there is little point continuing to complain you didn't like the result.

[Enigma2Illusion]

I'm sorry, I can't find where Mounir said that.

http://sourceforge.net/p/veracrypt/discussion/features/thread/ec4a617c/#a2e2

The discussion has been over for some time on the forum, you and Mrere need to accept that. A conclusion was reached, there is little point continuing to complain you didn't like the result.

Mounir asked for additional feedback for his latest proposal of a downloadable addon and I provided Mounir with my feedback for the addon and gave my assessment of the iteration issue. I am not complaining. In my opinion Mounir will need to take a stand on the iteration issue and announce his decision which is not going to please everyone given that no agreement on the various solutions for pro/con of the Dynamic Mode can be reached.

Edited to fix grammar errors.

[Mounir IDRASSI]

Thank you Enigma2Illusion for your previous post. I like this type of calm, professional and constructive posts and I'll prepare an adequate answer.
Since I started VeraCrypt, I have chosen paranoid level of iteration to give a fixed strength for the coming years. The configuration idea is something new and useful for a certain category of users and I'm willing to add in a form or another.
I'll post more details at the end of this very long thread...I didn't imagine that this subject will so controversial!!

[Anonymous]

This whole discussion is hilarious and much of it outright stupid.

Allowing people to get the faster derivation function they request as an option is not a security problem at all. If the kind of security some posters here say they need are to actually be implemented there are other points that need to be addressed, but those that need that kind of security should really use something completely different.

Against an attacker where it would be a real life problem you would need to enforce strong passwords, not showing any input on-screen while typing and using a on-screen keyboard with a random layout, etc. The KDF is the least of the problems against such an attacker. How about taking this seriously and not pretend to need security to stop the likes of the entire weight of the NSA? They would just grab the password with a keylogger, capture it over the air from wireless keyboards or send you to be beaten up or locked away until you tell them everything.

[Anonymous]

The TC audit suggests:

"Support the use of configurable iteration counts for PBKDF2 to keep pace with advances in CPU and GPU speed"

Configurable iteration would not only give the user who want to change it for speed the power to do so, it would also make sure that should development stop for some reason, those who still use it can turn it up should they want to. At least until something else like scrypt or a faster bootloader is implemented.

[Anonymous]

"Crypto is bypassed, not penetrated"

Shamir's law

[Anonymous]

If the kind of security some posters here say they need are to actually be implemented there are other points that need to be addressed, but those that need that kind of security should really use something completely different.

This is the point, there is nothing different, VeraCrypt is all we have.

However for those not facing a serious threat model there are many options, why they refuse to use them and demand to cripple VeraCrypt is simply selfish or malicious.

[Anonymous]

"Configurable iteration would not only give the user who want to change it for speed the power to do so, it would also make sure that should development stop for some reason, those who still use it can turn it up should they want to."

+1

Freeman

[Anonymous]

VeraCrypt does not get crippled by giving users the option to use lower iterations, I do not see you anywhere protesting against the one character password. Both makes sense and the software does not get any weaker by having these options.

Other question L0ck: why don't YOU use other software that fits your needs? Why do WE (the majority) have to go and you can stay?

Mounir says he builds the software for (almost) everyones needs so stop telling him he should drop 75 percent of the community to make 10 percent happy (15 percent probably don't care...).

He already announced a middle way and that is creating an addon or a dynamic mode, nothing wrong about that.

@Mounir: when you should decide to create an addon for the lower iterations, will you then allow a free number of iterations to choose with minimum of 10.000 or will you pretend a fixed number to use? Will you allow to mount volumes with lower iterations with VC that has the addon not installed? I think that would make sense, so people can create the volume with lower iterations by using VC + addon and then after that mount the volume also with the standard VC version without the addon. Nobody would get hurt by that, what do you think?

Freeman

[Mounir IDRASSI]

The post from Enigma2Illusion (https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/#4bfe/2010) is constructive as it remains objective and outside any controversy. The following is my answer to this post and other various questions.

The idea of static mode / dynamic mode is the one that I'm going to implement. It is a mandatory step towards having configurable VeraCrypt security settings which are necessary on the long term.
The disagreement is about the lower bound of iterations allowed by the dynamic mode. My current position is that the standard VeraCrypt distribution will have a lower bound identical to the current level, and the addon/Lite version will activate the possibility to have a small lower bound when using long passwords(30k normal volumes, 10k pre-boot authentication).

Going back to the list of tasks listed by Enigma2Illusion, in light of what I have explained above, the bootloader task is seen as parallel to the static/dynamic mode work. It will thus be handled once the later is finished.

What remains is the choice between the Addon option and the VeraCrypt Lite one.

One important point before going into this: the value of the lower bound of iterations will only affect that creation process of volumes. VeraCrypt (no matter what version or Addon present) will mount any kind of volume no matter what the value of iterations used.

Thus, the difference between VeraCrypt standard and VeraCrypt Lite/Addon will be limited to the volume creation wizard and only in the dynamic mode.

The Addon option makes sens on Windows since we only have to replace "VeraCrypt Format.exe", but on Linux/MacOSX everything is include in the main VeraCrypt binary and so we'll have to replace it.

So, in order to have an identical deployment strategy across all operating systems and reduce the global work load, the only left possibility is to have a separate build that would activate the possibility of creating volumes with lower iterations in dynamic mode.

I had several discussions off-list with security professionals concerning this (sometimes it helps to know with whom you talk!) and there are two arguments that came out of this which have their weight:

• At this early stage of VeraCrypt adoption, having two "product lines" of VeraCrypt can have bad image effects and also be confusing since the difference only affects the creation of volumes and only the allowed minimal bound of iterations.
• Using a one character password or a very short one (like a pet name) is currently allowed and it is as disastrous as using a very low iterations count. Moreover, since the current iterations count will be kept as the default and the lower iterations can only be set in dynamic mode with long password, a warning in this case will have the same security as the warning for short password.

I have to admit that the second argument was difficult to fight against. My position has been to forbid the user from choosing lower iterations even if the password is long enough because we can't be determine if the password is secure or not, but as pointed out, if I want to be coherent, I'll have to also forbid the use of short password...

The only philosophical point is the following: does having a default high iterations count while allowing a user to choose a lower value when using a long password makes VeraCrypt less secure?

At the risk of making hardliners unhappy, my current answer to the above question is no, VeraCrypt will still be secure especially that one can use even higher iterations count. Indeed, this is a position change from my side but I think it is the best approach that will benefit everybody, including highly paranoid users.

Concerning the bootlaoder optimization, this will take place afterwards.

[Anonymous]

Freeman / Mrere

VeraCrypt does not get crippled by giving users the option to use lower iterations,

Iterations protect the user password from massive brute force attacks. Reducing iterations reduces security, this is basic.

I wonder if you would accept an encryption program that used 1 iteration of the password hash ? If your answer is no then you accept iterations increase security and therefore reducing them weakens it. I believe you were just 0wn3d.

do not see you anywhere protesting against the one character password. Both makes sense and the software does not get any weaker by having these options.

I have no real objection to forcing a minimum password length, however there are other uses for short passwords which may help protect users.

The reason I fought to defend VeraCrypt full was this would have been the first time since it's creation that VeraCrypt would have experienced a regression in security. The low password length feature was already there, it was not added.

As my Lite suggestion seems to have been adopted (see topic), I am not really concerned how weak Lite is. Users employing Lite are clearly not interested in security and by their own admission have no real need for serious protection.

Other question L0ck: why don't YOU use other software that fits your needs?

There is nothing else for real crypto geeks, there is plenty of other software catering for the general unskilled teenager or those not requiring real security. VeraCrypt's conception was to be software for the paranoid, as the title says.

Why do WE (the majority) have to go and you can stay?

This is not true, there are a few people out of thousands of VeraCrypt users requesting this. One in particular making more than one user account. You are making figures up, again. There will be even less demand for this once the boot-loader is updated.

Mounir says he builds the software for (almost) everyones needs so stop telling him he should drop 75 percent of the community to make 10 percent happy (15 percent probably don't care...).

Again more made up figures. Lying will not help your case, however it rather helps prove mine.

He already announced a middle way and that is creating an addon or a dynamic mode, nothing wrong about that.

It was my suggestion LOL. Dump these types of users on Lite.

Check the forum where I made a topic requesting Lite and many comments about it during the long running thread. I have no objection to a separate weaker version, I have said this all along. I don't see why VeraCrypt should have to cater for those with no serious need for security, there are plenty of other options for you.

What I could not understand is why not allow VeraCrypt to be a no compromise example to others to follow ? Allow it to set the standard, by attempting to drag it down to a "populist" option according to your made up figures, only makes it blend in with all the other encryption software. I want the best for VeraCrypt, keeping it pure and 100% security is the only way.

Fortunately the few users who attempted to affect the full version of VeraCrypt have been thwarted, which is all I wanted. You should check the thread on the forum to understand why.

There also seems to be some confusion, about my position on the user choosing iterations in VeraCrypt full, I am all for it and I have mentioned this on the forum. My argument was the minimum allowable, which should be and looks like it will remain as it is now.

Hopefully this will be the end of attempts to weaken VeraCrypt full. Any further poor security implementations can be incorporated in Lite from now on and leave VeraCrypt full for the purist or paranoid as originally intended.

Mounir

The only philosophical point is the following: does having a default high iterations count while allowing a user to choose a lower value when using a long password makes VeraCrypt less secure?

At the risk of making hardliners unhappy, my current answer to the above question is no,

LOL You didn't think I would let you get away with that did you ??? :)

[Anonymous]

Great choice, Mounir! You think logically and are not afraid to change (carefully) positions.

So are you still open for suggestions how the iterations will be set for dynamic mode?

I would choose the following: normal iterations (I forgot how much is normal now) until 20 characters and everything above 20 characters including Aa1#-characters the user can use 10.000 or higher for pre-boot partitions and 30.000 or higher for other volumes.

Will you also allow higher iterations than normal under static mode? So when the development of VC should stop VC can still be used in the future with even higher iterations? Will you use fixed numbers like 10.000 or will you allow to choose free numbers like 10.233?

Freeman

[Enigma2Illusion]

Thank you Mounir for your kind words regarding my posts and taking the time to explain your decision.

Since you will be creating a separate product for the Dynamic mode to allow lower iterations with password length restrictions, I am thinking of new names to distinguish between the two products and to avoid product confusion from the feedback you received from your security professionals.

One idea is to distinguish VeraCrypt by editions. Much like Microsoft does for Windows.

Have the GUI windows display the edition like other software vendors when they have different features for the same product name.

Current Idea

• VeraCrypt becomes VeraCrypt Professional
• VeraCrypt Lite becomes VeraCrypt Premium

This leaves room in the future for lower and/or higher editions:

• VeraCrypt Basic
• VeraCrypt Ultimate or Enterprise

Does the VeraCrypt community have alternate naming nomenclature for the editions?

[Anonymous]

@Enigma: he will do seperate builds of veracrypt? I read his statement now several times but I don't understand if he wants to do now two versions or just one with the dynamic mode.

Mounir please enlighten me.

You say that offering the dynamic mode as an option does not make VC less secure but on the other hand you want to create two seperate builds?

Freeman

[Anonymous]

Well, most people here are complaining about boot times of under a minute. I just tried latest VeraCrypt 1.0f-1 with standard settings (AES, SHA-256) on a first-generation Core i7 laptop and it's hanging for almost 4 minutes at the boot screen...
Does it really perform that badly nowadays? Is there anything I can try?

[Mounir IDRASSI]

What is the reference of your Core i7 CPU? 4 minutes is too long and not normal. I suspect that Turbo Boost is not enabled and since the bootloader runs in a single core, this core uses low speed that may explain this bad performance.

[Anonymous]

So I just switched from Truecrypt to Veracrypt and successfully encrypted a container on my local hard disk, a usb drive in traveler mode, and an entire external usb portable drive. Now I see from reading the forums that it will take longer than Truecrypt to open up these various items because of the enhanced security, and the time isn't bad at all for the container and the usb drive, but the disk tales 5 1/2 minutes from the time I enter the password until the drive mounts unencrypted (That time is repeatable each time). That is with 4 hyperthreaded processors running 30% to 50% capacity for the entire 5 ½ minutes, the processor fan spinning up very loud at various points. The drive is an external 1 TB WD usb drive. I encrypted the disk (or should I say partition as noted in the mount point) using all the default values of Veracrypt. Does that sound normal?

Can I tweak some of the values to shorten the time and still have reasonable encryption because that is a bit much, and can they be tweaked without re-encypting the drive again (That took 10 hours because there was data on the drive)? All I care about is if someone were to steal the drive that they could not access my personal information; I suspect that the average person has like zero chance of having access to a computer farm so that they can crack the encryption, so maybe the default encryption settings are a bit overkill? Then again I guess I could live with the 5 ½ minutes as I don't use the drive every day, if that would offer better peace of mind.

[pjc123]

UPDATE: I tried this on another computer I have with an almost identical Intel motherboard (DP55WG instead of the more advanced DP55KG), the big difference being that the DP55WG has 4 processor threads instead of 8. It actually took less time to open up the archive (2 minutes 15 seconds, which is less than half the time) with the lower spec DP55WG configuration, also very repeatable unencryption times. Pretty strange indeed.

[Mounir IDRASSI]

Thanks for the update.
Just to confirm, are you observing the same long mounting time with the container and USB drive or it happens only with this partition?
Are you selecting the correct PRF algorithm in the password dialog?

Concerning your remark on the processor threads, once must remember that having more processor threads available doesn't mean that the machine will be quicker, sometimes it means the opposite and you just experienced that. It also depends on the CPU used, the number of physical cores and their maximum frequency and also Turbo Boost mode activation.

[pjc123]

There is a duplicate and more detailed thread on the VeraCrypt website, so I am ending this one to avoid confusion.... my bad.

[Mounir IDRASSI]

Hi all,

Sorry for my late feedback on Enigma2Illusion and Freeman posts as I was not available to monitor this discussion.

Concerning my previous post, I think that the way I wrote it can indeed be confusing. I tried to express the logic I followed in order to address all the queries:

• Having two separate builds is the only possible option (Addon is out)
• Two VeraCrypt "product lines" can be a bad choice
• Allowing the user to choose lower iterations when using long passwords doesn't make VeraCrypt insecure.

Using these elements, I wanted to conclude that the best choice is to include in the standard VeraCrypt the dynamic mode that allows choosing lower iterations for strong passwords.

Enigma2Illusion proposal of having VeraCrypt editions is interesting as it offers a more professional approach to VeraCrypt naming issue. My position for now is to include the dynamic mode in the standard VeraCrypt version but I keep this idea on my mind as it can interesting to ship advanced features in a separate build.

To summarize:

• By default, volumes will continue to be created like today (static mode)
• User can choose dynamic mode to increase iterations from current level during volume creation. If the password is longer than 20 characters, he will be able to lower iterations count but not below a certain minimal limit (30k normal volumes, 10k pre-boot authentication)
• Volumes can be mounted no matter which mode was used to create them and for any iterations chosen.

Concerning the choice of iterations, my idea is that the user will enter a value that will be transformed to the iterations count using the formula: IterationsCount = (1024 x UserValue) + LowerBound
If the password is less than 20 characters, IterationsCount can not be lower than 500000 and so UserValue has a minimal value. When the password is longer than 20 characters, UserValue can be freely fixed (0 accepted).

The dynamic mode implementation is important for the future of VeraCrypt as it will enable the increase of iterations in the future. Its implementation in the bootloader is challenging due to the size constraints but hopefully I can come up with an optimized implementation.

[Enigma2Illusion]

Thank you Mounir for clarifying your decision. Sorry I misunderstood your previous post. I prefer the approach you are taking of one product version.

[Anonymous]

Alright, that sounds great.

Is it planned for the next version to make system partition transformation from TC to VC possible?

[Mounir IDRASSI]

It is planned but it is not a priority. Depending on how the development of static/dynamic mode goes, it can be implemented on time for the next release scheduled on April.

[Anonymous]

My Core i7 is a Core i7 640LM with TurboBoost enabled. I have just tried it again multiple times and the 4 minute boot time stays.
I hope a lower iteration count will be implemented soon as this currently blocks my use of VeraCrypt (and subsequently the use of this machine).

[Mounir IDRASSI]

On an Core i7-2600K, booting with SHA-256 takes around 58 seconds. If we use the CPU benchmark values of http://www.cpubenchmark.net/cpu_list.php, we get:
- Core i7-2600K => 8567
- Core i7 640LM => 2315

This a 3.7 factor which theoretically means that boot time with a Core i7 640LM should take around 3 minutes and 35 seconds, which is close to the 4 minutes you are observing.

In the next VeraCrypt, it will be possible to use lower iterations when a long password is specified. This will make encryption more usable but it will be very important to choose a really strong password.

Another step will be the implementation of a 32-bit bootloader which will give us a 3 times faster boot. This would mean in your configuration a boot time of a little more than 1 minute when using default VeraCrypt security parameters.

[Anonymous]

Just to be sure:

Will we be able to use long passwords (more than 20 or 30 characters) AND STILL having 500000 iterations or more? I like the idea of increasing them.

Will volumes with low iteration levels explicitly say: 'VC Lite Volume' while mounted ? I think it would be confusing sometimes, like: ' Did I create this volume with HIGH or LOW iterations? '

I suggest adding such thing.

Nice new image! Nice design!

[Mounir IDRASSI]

Thanks for the feedback.

You'll always be able to use the current iterations (500000) or even higher.
VeraCrypt will never force you to use low iterations and the default mode (static mode) will be the same as today. The dynamic mode will allow choosing iterations higher than 500000. If your password is longer than 20 characters, then and only then, you can choose a lower iterations but you can still choose higher value, it is all up to the user in this case.

When mounting the volume, either the user doesn't specify anything concerning the iterations and in this case, VeraCrypt will try to mount the volume with the current iterations count (500000), or the user explicitly tell VeraCrypt which iterations to use.

In both cases, the user knows what is the iterations level that is used, and so I don't see any confusion or any need to add an information about this in the volume properties.
Did I miss something in my logic?

[Enigma2Illusion]

Hello Mounir,

Proposal # 1

I would like to propose the number of iteration counts be stored in the header. The static mode is a fixed number of iterations, hence anyone brute forcing the hash knows the number of static iterations to attempt. My point is that storing user configurable iterations does not create a security vulnerability.

Proposal # 2

Another proposal is to give the user the additional option to store the user configurable iterations in the header so the user does not have to remember the value for each volume which may be different or in cases where there are multiple users of a system accessing multiple volumes.

The above proposal should satisfy people who would prefer to use Dynamic without providing a hacker or an agency clues as to the number of iterations used for the hash and provides the usability to users that have a different threat model to configure storing the number of iterations for each volume in the volume's header.

For your consideration are some scenarios for storing the number iterations in the header.

1. User may forget the number of iterations for an archival volume that is accessed infrequently. What happens if a user cannot remember the number of iterations?
2. User may not remember the number of iterations when they have multiple volumes with varying data sensitivity. For example, the user may consider volume X as having very sensitive data and volume Y with less sensitive data. This forces the user to remember each volume's iteration values which will likely lead to the user writing down or storing in a file somewhere each volume's iterations.
3. Multiple users with access to the same multiple volumes must remember the number iterations.

Thank you for clarifying the implementation of the Static/Dynamic modes.

[Mounir IDRASSI]

I don't see the difference between your two proposals since they all require storing the iterations on the volume header.

Anyway, I will not change the storage format which will remain filled with apparent random data. Adding such information to the volume will break this principal and it will have other consequences. So, the iterations information will not be stored on the volume.

As I said previously, static/dynamic mode modification applies only to the creation of volumes. For the mounting of volumes, there will be a field where the user can enter the iterations indicator:

1. If this field is empty, VeraCrypt will use the current iterations count (500000)
2. If this filed in not empty, VeraCrypt will calculate the iterations count from its value.

My current idea is that this field will be in the "Mount options" and thus it can be stored when a volume is saved as a Favorite.
So, if the user fears forgetting the iterations count of the a volume, he can either:

1. avoid creating volumes with dynamic mode
2. add the volume to the favorites.

[Enigma2Illusion]

Hello Mounir,

I understand your points for not changing the header to include the iterations.

I don't see the difference between your two proposals since they all require storing the iterations on the volume header.

Just for clarification, proposal #1 will require the iteration in the volume header and proposal #2 would be a user option to store the iteration in the volume header instead of entering the number of iterations.

Thank you for considering my proposals and explaining your reasons for the rejection. :-)

[Anonymous]

You explained well!

I meant that having many mounted volumes, I would like to know which one has low iterations, maybe in properties.

Thanks for adding the option to increase iterations.

Veracrypt is an amazing software/project and it's good that we are all integrated and our opinions matter.

JeSuisVeracrypt

You've mentioned your supportive wife, thanks to her too! Cheers!

Veracrypt is my favorite program!

[Anonymous]

OFFTOPIC

Mounir, you said that transforming TC system volumes to VC system volumes is on the list but it will take at least a few months. I am perfectly fine with that but then I need a workaround to switch to VC.

On one PC I use an SSD which is encrypted with TC, now I can not simply decrypt it with TC and encrypt it with VC again because of the wear-leveling. So when I encrypt it again with VC (and I leave 10 percent unpartitioned) then there will be data unencrypted in the 10 percent free space. Even when I would leave no 10 percent free, then the SSD still has capacity unencrypted that is used for wear-leveling when the SSD is completely full.

So how can I switch to VC now? The only possibility I see is booting with a Live CD, mounting the system partition with TC, copying the data of C: on an external drive, then formatting C:, installing Windows again + VC, booting into Live CD and copying the C: backup onto the VC system partition.

Would that work? Is there a more simple solution?

[Mounir IDRASSI]

Yes, this should work although the formatting of C: in not needed since the drive is already fully encrypted.

For now, there are no other solutions. I received lately many requests about converting TC system volumes so I'm thinking of delivering a beta version including this feature earlier than anticipated. Stay tuned.

[Anonymous]

Thanks for that, I bet a lot of people will be thankful for that! I personally could not wait anymore and switched now with a bit of work... but now it's done.

But a thought that came to my mind is the following: when leaving 10 percent of the SSD free and encrypting 90 percent, there will be very likely data leakage when you encrypted the SSD AFTER you put sensible data on it. BUT now my idea: the longer you will use the SSD the more of the leaked data will be overwritten with encrypted data by the wear leveling mechanism... you can also encrypt the 10 percent free space and then decrypt it again for wear-leveling. Now you overwrote 100 percent of the SSD and you should be fine.

I read that most SSDs have more flash cells than advertised which are used as replacement for dead cells or for wear leveling when the SSD is 100 percent full. Would be interesting to know more about that topic. But it would be immense effort needed to get to this data and the attack is more theoretical than practical.

Just some thoughts.

[Anonymous]

Here a german people for support?
Um nicht unnötig zu spamen oder Beiträge zu verfassen schreib ich schon mal mein Problem.

Ich habe VeraCrypt installiert und wollte nun die komplette Festplatte verschlüsseln.
Beim booten kommt: bitte passwort eingeben....eingetippt....und dann blinkt nur noch der Cursor.
Passwort ist definitiv richtig, habe auch schon andere Passwörter getestet ebenfalls das Problem.

[Enigma2Illusion]

What version of Windows are you running? Do you have System Reserved partition on the system drive? If yes, you can only encrypt the C partition and not the entire drive. Otherwise system will not boot-up.

How long did you wait after entering password? VeraCrypt high iterations take a lot more time than TrueCrypt using 16-bit bootloader.

https://translate.google.com/

[Anonymous]

Veracrypt braucht einfach sehr lange beim Systemstart, ist ein Sicherheitsfeature gegen Bruteforce, ist nervig und es wird in Zukunft eine Funktion geben, um die Dauer deutlich zu verkürzen. Musst also je nach System mindestens ne Minute warten bei AES und SHA256!

[Anonymous]

I think the VeraCrypt Homepage should state more clearly who VeraCrypt is and ISN'T for.

I want to encrypt my laptop in case it gets stolen or lost.
There isn't anything overly sensitive on it, and I do not fear targeted attacks from government agencies or hackers.

Adding two minutes to my boot time isn't worth it to me.

I guess TrueCrypt is a better product for me, but I would have liked to know that before trying VeraCrypt.
I initially picked VeraCryt over TrueCrypt because it's still being supported and has better documentation.

[Mounir IDRASSI]

I understand you position. VeraCrypt is targeted towards high security and for normal use cases the boot delay may be an overkill.

A possible solution for you in the future is to use the dynamic that will be introduced since it will be possible to use less iterations (thus quicker boot) if the password is long enough (20+ characters). This will give a similar security level provided that the password is really strong and not only composed of patterns to reach the needed length limit (20).

[Anonymous]

I use win 7. I wait circa 60, 80 seconds.
I have full encryption with all partitions. Its running but the start is slowly.
I think full encryption is more secure.

Nice weekend und a lot of thanks for this program :)

[Anonymous]

"Nice weekend und a lot of thanks for this program :)"

Captain: Mayday, mayday, we are sinking!!!
German coast guard: what are you thinking about?

I personally have exactly 60 seconds until VC boots, I think with the the current build it does not get any quicker than that with an SSD and i7-5820K.

Freeman

[Anonymous]

I don't think that storing the iteration count in the header is a good idea. It sort of defeats the whole purpose of implementing the dynamic mode in the first place. I suppose that if there is a way for VC to somehow "recover" your forgotten iterations count from the header, then in theory any attacker could do the same. As I see it, the main reason for the revolutionary dynamic mode is the introduction of an additional (highly customizable) factor of authentication, which, combined with all the other existing options would make any attempts at brute-forcing a VC volume practically unfeasible. The number of various factors to consider would be overwhelming. This dynamic mode will be optional, and I would assume that if someone would choose to customize their iterations, they would know what they are doing in the first place, and thus would be unlikely to forget their settings easily.

[Anonymous]

I think I did not understand the problem. Why do you have to know the iteration count you chose for a volume? Can't Veracrypt try it out until it gets the right amount of iterations when mounting the volume?

[Mounir IDRASSI]

Technically it is not feasible to try all iterations count incrementally. The way PBKDF2 is specified, for every iterations value, we have to perform a specific computation so if for example we already have perform the PBKDF2 computation for N, we can't use its output to calculate the PBKDF3 for (N+1): we are obliged to calculate PBKDF2 for N and for (N+1) separately. As you can imagine, this make the iterative guessing of the iterations count computationally impossible (which is good for security).

Thus, if the user doesn't use the default VeraCrypt iterations, he must tell VeraCrypt which value to use.

[Anonymous]

Thanks for the explanation, so using for example instead of 500.000 iterations it would be even more secure to use for example 439.023 iterations so even when the password was keylogged the attacker still has to bruteforce the correct iteration number?

[Mounir IDRASSI]

Making the iterations count configuration adds another security layer to the encryption. This is planned for the next version.
Since VeraCrypt will not know this value, it has to be specified somewhere, either through the password dialog by entering it manually or setting it on the preferences. In all cases, if a malware or virus is present on your machine, he will be able to recover this value alongside the password.
VeraCrypt or any other encryption software can't protect you from malware. Usually, malwares tend to focus on stealing passwords and other textual information, so the use of a keyfile in addition to a password can bring some kind of protection against such threats.

[Anonymous]

Speaking of malware, there are a number of free tools that can effectively protect from screen and keyloggers. But what are the chances that, instead of spying on your password, a rootkit could be implanted via a malicious attachment, in an attempt to steal the plaintext master key from RAM and silently send this data remotely over the internet? I suppose that for this to work you will have to transmit an entire memory dump, which especially in modern computers could well be above 8 GB in size. But if this happens, does it mean that your only option is to re-encrypt the entire drive (since changing password won't help because the plain text master key, which cannot be changed, was identified in the memory dump)?

[Enigma2Illusion]

There is always the risk of hardware/software keyloggers or "Evil Maid" attacks. I have read that some products will scan certain known memory locations for the encryption the key.

There are good explanations provided in the documentation regarding Security Requirements and Precautions.

[Anonymous]

I put VeraCrypt on two brand new computers, excited and hopeful that this would replace Truecrypt. I only encrypted the system partions drive. After encrypting and rebooting, one took over 4 minutes to authenticate the second hasn't authenticated yet and it's been over 8 minutes. I am going to have to remove it and try another product. The boot time is way to long for productivity in the workforce. I am disappointed.

[Mounir IDRASSI]

This is frequent complain. I talked about it in length and I will not repeat all the arguments and the ideas. You can go through the discussion to understand the situation and the future evolution.

One point though: a brand new computer doesn't mean that this computer is powerful. Without giving the CPU type, one can't give an objective analysis.

[Anonymous]

It would be very productive to add a "READ FAQ before downloading" on the front page.

or

"What you have to expect from Veracrypt - What do you intend to do with Veracrypt?"

It seems that some people never read before downloading and probably don't know the differences with Truecrypt.

[Anonymous]

" Since VeraCrypt will not know this value, it has to be specified somewhere, either through the password dialog by entering it manually or setting it on the preferences. "

Is this option possible on disk encryption? If I select dynamic mode with less iterations and long password, will there be a place where I type the iterations I used?

I'm very sorry if I missed something.

[Mounir IDRASSI]

Yes, the idea is to have a prompt during the boot that asks for this information before the password prompt. If it is left empty, the current iterations value will be used.
Nothing is implemented yet on this part. Adding dynamic mode is not an easy task...

[Anonymous]

Thank you for your efforts and good luck!

[Anonymous]

1:15 to pass the bootloader on a last gen Core i3.
Do you have an ETA on that 32-bit upgrade for the bootloader?
Thank you for your work.

[Anonymous]

i have read the discussion and i have two comments to add.

1. Configurable iteration count. Does VeraCrypt intend or encourage its on-disk format to be used by other projects? Different iteration counts means different formats and it may be difficult for other projects to properly support VeraCrypt volumes if it starts having multiple formats that are incompatible with one other.

2. Judging password strength based on its length(less that X characters == bad,atleast X characters == good).There are tools like libpwquality[1] that i think does a better job of judging the strength of the password and i think VeraCrypt should use similar approach.

For example VeraCrypt with the current proposal will say a 22 character password made up of only character 'x' is strong enough but libpwquality will give such a password a zero grade!!.

There are longer password that have little strength with them and there are shorter ones that are much stronger.

[1] https://fedorahosted.org/libpwquality/

mhogomchungu

[Mounir IDRASSI]

1. One of the objectives of VeraCrypt is to make its format usable by other software as it was the case with TrueCrypt. Having a dynamic iterations count will not change the storage format but just the parameter used for PBKDF2. Current implementations found in tcplay or cryptsetup use hardcoded values for these iterations count (500000 for VeraCrypt). These values will remain the default for VeraCrypt but I'll introduce the possibility for the user to choose a custom iterations count. In this case it is easy to modify the other software: just add an option for the user to specify the iterations count. If nothing is given, the software will use the default hard coded value (500000). If the user specify a value, it will used instead of 500000 in PBKDF2 computations. In all cases, the storage format is the same and it will not change.

2. Indeed, adding a better password strength evaluation function is an important feature. This will make VeraCrypt more modern as this type of strength evaluation is now mainstream. Implementing a new one from scratch is something that I would like to avoid so reusing a well proven library is more than welcomed. libpwquality is a good candidate thanks to its dual license. I'll have just to check how does it handle UNICODE characters as this is something that I'm planning to add soon in VeraCrypt.

[Anonymous]

dynamic mode: limit to increase iterations?

[Mounir IDRASSI]

Not only increase but also decrease if and only if the password is very long (20 characters at this stage).

[Anonymous]

Hm, why don´t you give the user a short feedback after he entered his password, like "Please wait...". I was testing verycrypt for 10x in my VM, and always thought it fails becose nothing happened after I setup my password.

[Enigma2Illusion]

This has been added to the beta version and will be available in the next release. You can download the beta version to get the feature which has "Verifying password ..." as the message.

[Anonymous]

I can't find any current beta version to download? And does the beta include already the dynamic mode option?

[Mounir IDRASSI]

The 1.0f-2-Beta is available in the Nightly Builds directory: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/
No, the beta doesn't include the dynamic mode as this feature requires more time to be finalized. All modifications done in this beta can be found here: https://veracrypt.codeplex.com/wikipage?title=Release%20Notes

[Anonymous]

It takes my brand new laptops 2 minutes plus to start booting after the encryption password has been entered. The people I build these for don't want to hear how much 'better' it is. Now I will need to find something quick that probably isn't secure at all.

[Mounir IDRASSI]

The boot time depends on the CPU used but also on the hash (using RIPEMD-160 instead of SHA-256 divides the time by 2).
As you can read in this thread, there are many optimizations planned for the bootloader (rewrite to 32-bit/64-bit, add lower iterations for long passwords).
So, stay tuned for new updates. Meanwhile, TrueCrypt is a good compromise for you until then.

[Anonymous]

After upgrading to SSD I decided to move from TC to VC for full system encryption.
Now it takes about 2.5 min on my recent, low-end laptop to boot. Like many, I only need to prevent petty thieves from seeing my personal docs. So, unfortunately I have to go back to TC. I hope you make this great software even better by addressing this issue.

[Anonymous]

Hello,

can I now select how many iterations it should be use? I already have an encrypted system drive and can't find this settings in the newst nightly build.

Thanks!

[Anonymous]

I already asked the same question 5 postings above, you should read at least two sites in a forum before you ask a question... the more we ask questions that were already asked before, the less time Mounir has to please his wife + kids? and work on VC.

[Anonymous]

Not sure what you mean. I don't think that this is the same as the dynamic method, you were talking about above.

[Mounir IDRASSI]

Actually, this is the same thing: in dynamic mode, the user will be able to choose the iterations count to use. I explained this many times in my posts.

Dynamic mode implementation is ongoing and it is not available yet.

[Anonymous]

I'm using an older laptop 1.60GHz 2GB RAM (only 80GB HD if that matters)

The time from when I press enter on after putting in the password until it starts to boot the OS is 5 mins 42 seconds. I used AES(Twofish) and SHA-512. My life is passing me by while I sit here waiting for veracrypt to boot. I'm thinking of decrypting the drive and then using truecrypt.

If I reencrypted and just used AES SHA-512 how much faster would veracrypt be? Would it still be like 3 mins on this machine?

[Mounir IDRASSI]

For such slow systems, you can select RIPEMD-160 instead of SHA-256: this will divide boot time by 2. RIPEMD-160 is not as secure as SHA-256 but it is still strong enough for "casual" use.

For the boot time, its is the PRF who takes most of the time not the encryption algorithm.

[Anonymous]

Any updates regarding the dynamic mode? Thanks

[Mounir IDRASSI]

There are difficulties implementing dynamic mode for system encryption caused by the size limit of the bootloader but nothing blocking.
Dynamic mode affects many parts of VeraCrypt (driver, creation and mounting logic, GUI) on all operating systems (Windows, Linux and MacOSX) so extra development and testing efforts are required.
The current planning is to have a beta version for this by mid May to receive inputs from users and adjust things accordingly.

[Anonymous]

Reading this thread, I am a bit worried about the choices made by the devs and whether they understand crypto at all.

The iteration count of a PBKDF (password-based key derivation function) is there to make brute-force attacks weaker by orders of magnitude, because passwords usually chosen by users are not "cryptographically strong" and deriving a key directly from those passwords results in a key that is not sufficiently cryptographically "random". So the password is fed into cryptographic hash functions whose output is "strong" enough to be used as a key.

That said, the iteration count is meant to reduce the brute-force capability from testing billions(!) of passwords per second to a much lower value. Even reducing this to 1000 tries/s is sufficient to thwart a brute force attack. Heck, if you want to be "ultra secure", one(!) try per second is enough, i.e. 1s per tested algorithm is more than plenty with regards to the PBKDF.

What's way more important is to choose a "good" password. Mindlessly cranking up the iterations so that the whole thing becomes a usability hindrance is not a good idea. Evidently, many people seem to think that if it takes a minute to boot your computer, that you are somehow "ultra secure".

You are not insecure because an attacker can try 1 or 10 or 100 passwords per second when the normal mode of operation is billions per second. People need to get an idea about the numbers we are talking about.

A (completely random) string of just 16 characters consisting only of lowercase letters, uppercase letters and numbers has about 95 to 96 bits of entropy.

Attacking 95 bits of entropy with 1000 billion tries/s takes about 628077138 years to crack. Cranking the iterations up so that the tries per second go down to 1, you increase that to 628077138145804299796 years. What good is it now to increase that further by a factor of 60?

The password quality is way more important and I'd rather see an indicator going from red to yellow to green when entering the password at creation time or introducing people to the concept explained at http://world.std.com/~reinhold/diceware.html for example. I think a simple red indicator does more for the feeling of security in the average user's mind than waiting 1 minute to boot. The goal should not be to encourage weak passwords by telling users that the iteration count will compensate for their weak choice.

If you make your product unusable so that people who don't understand crypto can feel secure, when all they had to do was choose a good password, you are hurting the global cause because less people will use VC.

Regards

[Anonymous]

What he said. I'm going back to truecrypt where I don't have to wait THREE minutes to boot.

[Anonymous]

Oh and one more thing. You if introduce multiple modes with differing iteration counts, may I suggest that you don't use a scale of "weak", "less secure" and "secure" but rather "secure", "mindlessly paranoid" and "I-don't-understand-crypto secure"?

Because if you extrapolate the design decision of a 1-minute-to-completion iteration count to protect weak passwords, you should be using iterations that take 1000 years to complete to compensate for the user that chose a 1-character password.

[PIK]

Hi girls and guys. And sorry for my english...

Now all is only imho ;-)

Sorry but the "slow boot" is not acceptable. All over 15s on Athlon500 is not acceptable. High iterations count is security issue -> This is not to communicate, you must waiting 60s before your machine starting boot sequence. Simply people using worse solutions, then boot after 2s.

1min waiting is a deterrent feature.

I cant understand this degree of freakness. Sorry.
Has someone calculate, also with little fantastic assumptions for power of ASCIs and GPUs, how many years the attacker need to bruteforce 2000 iterations of 13 signs password?
Once look to any data from oclHashcat site?

What is the mind the security, than Tianhe-2 can bruteforce in 2807713 years, incrase about COEFFICIENT 60??

What are we going to do here? We make soft for each or we make technology studies? Hey PAQ8HP12 is a fantastic compressor. Wow. Really. And? The guys here than wont xx.xxxx iterations, using PAQ? Or 7-zip, Winrar bzip2 and and. WHY? Why not PAQ8? ;-)

Question: Is 32bit bootloader for ridiculous big iterations and GPT-support possible? How many construction zone we need? (Yoda is the best ;))

Please,
2000 iterations for passwords >=13 signs.
5000 iterations for less signs.
dont accept passwords less 6 signs.
show a warning message, than short passwords than 13 signs results in significant longer boot prozess.

p.s.:
Who veteran-user with a good password will wait 60 seconds for start the boot process, because we must also protect clueless house-painter?

Sorry. All best with any another fix, change or feature in VeraCrypt, BUT THIS is simply unbearable.

If you make software for freaks, only freaks will use it.

[Anonymous]

It seems that most people don't care much about their security. Convenience, at all times, is the goal of the masses. If you encrypt your PC to keep out your wife or some random thief then you should simply stick with truecrypt or bitlocker. It'll do the job just fine. For the rest of us, who truly value security over convenience, compromise is not an option. Most people are not capable of remembering a 60 character fully random password. Dictionary permutations & keyspace narrowing remains a viable threat. A "ridiculously" high iteration count serves as a general deterrent. No adversary would bother brute-forcing such a system, as it would be widely assumed of being a pointless waste of time and resources. And that's where VC stands out from the crowd.

[Anonymous]

People who care about their security choose a good password.

If your password doesn't withstand a 1/s attack, another factor of 60 is not going to make a difference.

Bringing the brute force capability down from millions and billions of tries per second to just one per second is absolutely sufficient.

The fallacy that if your containers mount fast, then they must be insecure is perpetuated by people who simply don't understand crypto and the numbers involved. Such people are much more likely to be influenced by a red indicator saying that their password is weak, than by ridiculous waiting times.

[Mounir IDRASSI]

Without going back to a long debate, I have posted an brute force attack estimation using the latest ASIC hardware:
https://sourceforge.net/p/veracrypt/discussion/general/thread/09696187/#491d
https://sourceforge.net/p/veracrypt/discussion/general/thread/09696187/#65da/ca99

Using the same methodology, a 13 characters password with good entropy would require hundreds of years to crack using a single ASIC. Actually, a good password starts to be strong enough from a length of 12.

From the security point of view, the extra iterations adds extra entropy to the password, but if the password is already strong, this brings no added benefit.

In the next version, users will have the freedom to choose lower iterations when using long passwords (12~20 long).

[Anonymous]

I've never posted here before, so firstly thank you for your efforts, Mounir.

Unfortunately I must echo the many others here saying that these waits are completely insane. Truecrypt was nearly instant (a bit too instant) and I'd happily deal with maybe 10s, but >1m on an i7-4770k is just unusable. This is long enough to drive me away from the project on desktop, and I'm happy I didn't try this on a laptop first, as I can't even imagine using this if I shut down and booted frequently (as any properly paranoid user should be doing when they leave the machine unattended).

Also the "try every algorithm in sequence" strategy in the 2nd post is even more insane. You're adding 3 bits of entropy via obscurity (8 algos listed there, and of course using "bits" there is apples to oranges because the cost of the algos varies, but you get my point) at the cost of punishing users who pick anything but AES with an even longer boot. I could more than recover those 3 bits with another character in a random password or another word in a passphrase. This isn't a reasonable strategy, don't make attackers guess what algorithm you're using, use a (slightly) better password! Most users will be using plain AES anyways, by virtue of hardware acceleration, being the default, and the speed-gouging described above incurred by using anything else.

Thanks for your consideration.

[Mounir IDRASSI]

Hi,

Thanks for the feedback.

I will only correct your second point since your first remark is similar to what have been said before and for which the dynamic will be implemented.

Although in the 2nd post of this very long discussion I mentioned the fact that the encryption algorithms were tried in sequence, this is actually the same as for TrueCrypt and it takes the same amount of time as in TrueCrypt.
In reality, the bulk of mount time is taken by the key derivation not encryption algorithm detection, so I should not have mentioned this in the first place. I already clarified this in a previous post but it is buried somewhere inside this discussion. Thus, your second point doesn't apply.

[PIK]

Hi (and you known, my english...)

On another hand, I mean, VeraCrypt need a method to defence not a 1, but ~2000 ASICs attack for hundred years. In the next 10 years.
I am not the best crypto-mathematician, but Is IT only possible with a >60s latency the boot process on i3?

I think for the security trade-off for boot volumes, its better to FORCE the user to use good >=12 characters password then force him to wait 60s for boot process.

Simply concerning of performance limitations of 16bit boot loader, hardcoded rules of the game for boot volumes should be different as for container and another volumes.

For dynamic mode I suggest benchmarking the system for suggestion to user of method and iterations. He must known the latency BEFORE crypting the boot volume. I suggest a autosensing-like function for it (like KeePass). With editable settings and hardcoded minimum values.

And what we dont forget, is a mindfu... social hacking of advocatus diaboli, with his /well-intentioned/ suggestions, which to propel you to make worlds hardest methods, for solutions which finally only handful people wants to use -> mission accomplished.

At the moment, still I can not believe than Ripemd-160 with 2500 iterations and suitable >12 password is not good enough against... Utah %-) Can anybody clarify me? Thx.

Otherwise for hacking your super hardened boot volume you goes to slammer (England) or you become finest trojan horse or electrodes on your ears. Or scrotum. Or you learn fancy diving in covertly romanian slammer.
For one of this experiences you have 2 years long wait each time >60s to booting your boot volume?

Hmm...

[Anonymous]

I would like to thank the developer for adding this option of lower iterations in the coming releases of Veracrypt. And a reminder to all you must rely on your own random and very strong password as th most important defense to start with.

[Anonymous]

The problem with long boot times is more than just a matter of convenience. If the boot time is too long people in our department will simply choose not to boot very often. And if a running laptop is stolen it is possible to read the crypto keys out of the RAM even if you cannot get past the Windows password. So, VeraCrypt is only useful if Windows has been shutdown when the laptop is stolen (sleeping or hibernating is not enough) and to encourage people to shutdown often the boot times have to be reasonable.

If you read the paper by Colin Percival that was quoted in the TrueCrypt code audit you find that he estimates the cost of building a machine that could brute force with one year of running time a single 10 character password encoded using PBKDF2-HMAC-SHA256 and 86,000 iterations. The costs alone for the special purpose chips implementing PBKDF2 in hardware would be 160 M US$. (Add in your disks and interconnect and you can double that.) And that is for one (1) password. Any state actor would want to hack a few dozen passwords per year, so they would need a machine that cost several billion dollars. (Did I forget to mention the costs of the power and cooling plants? Throw in another hundred million for those.)

Given Percival's estimate, I fail to see how the developers think 10 times more iterations are going to add any additional security to a sufficiently long password.

Remember the NSA had a great security system that was broken by a great feat of social engineering (Snowden).

[Anonymous]

Can the developer please advise if this is normal.

64GB USB
Device encryption
ExFAT
Previously TrueCrypt
Converted to VeraCrypt SHA 256.

Specified SHA256 mount option

Mount time 60 seconds.
This seems high compared to people saying they can mount 1.5TB in 12 seconds with SHA512?

[Mounir IDRASSI]

60 seconds is too much for a modern CPU if you explicitly specified the SHA-256 as PRF.

What is your CPU? maybe you are using some very slow one.

Are you using command line or the GUI to mount the volume? If you are using command line, can you post the parameters you are using just to check?

How do you calculate mount time?

On git, there are benchmark scripts that are used to compute mount speed for various algorithms. I'm attaching a zip that contains the benchmark files.
Can you please run bench.bat on your machine and post the results back?

For example, on a Windows 7 64-bit with Core-i7 2600K, it gives (unit in second):

SHA-256 (Normal) = 00:00:05,02
SHA-256 (Hidden) = 00:00:10,12

Thank you.

[Mounir IDRASSI]

I have upload the installer for version 1.12-BETA that includes a first implementation of dynamic mode. It is available on the nightly builds folder: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/

The dynamic mode is implemented through the introduction of a new fields called PIN, which is an abbreviation of Personal Iterations Number (this name was contributed by user Ollie). This field can be left empty or set to 0 to have the same behavior as before.
If a value is specified in PIN, then the iterations are calculated as follows:

• For system encryption: Iterations = PIN x 2048
• For non-system encryption and file containers: Iterations = 15000 + (PIN x 1000)

If the password is less than 20 characters, PIN must be greater than 98 for system encryption and greater than 485 for the other cases.
If the password is longer than 20 characters, PIN can be equal to 1 and upwards.

This version is for tests only since this is a new feature that needs further validation.

Thank you in advance for your tests and feedback.

[Anonymous]

Thanks very much for adding dynamic mode. This is a great enhancement. Keep up the good work!

[Anonymous]

i installed version 1.12, im using system partition, restart pc and worked normally, if i change password and change pin with value more high it will take much longer to load the system?

obs> sorry bad english...

whats default iterations of system partition using sha256 ?

[Mounir IDRASSI]

If you perform a change password operation and you set a pin value between 1 and 97, then the boot will be faster.
The boot will be slower if the PIN is greater than 98.

The default iterations for system encryption with SHA256 is 200000. This is equivalent to a PIN value of 97.

[Anonymous]

Awesome! Thanks!

[Enigma2Illusion]

Hello Mounir,

One minor change to the GUI label is to called it "Volume PIN" instead of "Volume Pin" since the PIN is an acronym for Personal Iterations Number which should be all uppercase letters.

As always, great work Mounir! :)

[Enigma2Illusion]

What are people's thought about renaming the Volume PIN to Volume CIN (Custom Iteration Number)?

My thinking is that too many people associate PIN to mean Personal Identification Number.

Or just call it "Volume Custom Iteration" in the GUI to be more descriptive instead of using acronyms in the GUI which leads to confusion.

[Anonymous]

I would choose Volume Custom Iteration.

[Enigma2Illusion]

After reflecting on the naming of this new feature, I think the following is more appropriate.

Custom Volume Iteration

[Anonymous]

Oh dear...

What could possibly go wrong re-using a security-related acronym for completely needless complexity. It's amazing how you can overthink PBKDF2 and end up with such a monstrosity of a user experience.

Please, hire some crypto guys who grok applied crypto.

[Anonymous]

PS: Remember still, these PIN shenanigans are supposed to "protect" users who choose weak passwords.

You expect users who can't choose a good password to make a good decision what their iteration count should be.

The whole approach is completely flawed.

Implement an auto-tuning to 1s CPU time per iteration with a fixed lower bound for very slow machines and be done with it.

[Mounir IDRASSI]

@Enigma2Illusion: the naming is temporary and all proposals are welcomed.

@Anonymous: In your comment, you fail to address the basis of the dynamic mode which is to have a two dimensional security parameter (iterations, pin length) instead of only one (pin length). This approach have the advantage of addressing both case of users since the tool enforces minimal password length.

Your 1s CPU time approach is flawed : how we are suppose to keep track of the automatic iteration value? Remember that VeraCrypt volumes content is indistinguishable from random.
Moreover, this approach is also flawed since it doesn't take into account the password strength: without this, you approach will give a false sens of security to users because they will rely on their own machine performance for the derivation security assessment. It can only be corrected by adding a check for password minimal requirements and in this case it will be as if VeraCrypt is choosing a hidden iterations value instead of the user him self.
But in all cases, I repeat, how we are supposed to feed this custom iteration to VeraCrypt so that it can mount the volume?

VeraCrypt is open to productive criticism but ,Mr Anonymous, before criticizing with such harsh words, you have to make a minimal study of the work and its context. I think you are mixing VeraCrypt with some encryption software the uses some XML file to describe the encryption parameter.
Once you understand the specifics of VeraCrypt, you are kindly welcomed to propose any alternative solution that takes into account all the parameters involved in the security of the scheme.

[Anonymous]

If you couldn't keep track of a dynamic value, how do you keep track of the "PIN"? Is the user required to enter it along with his password?

[Enigma2Illusion]

The custom iteration is not stored anywhere. You must remember the custom iteration value for each volume that was created with a custom iteration in order to mount the volume.

Is the user required to enter it [PIN] along with his password?

Yes.

[Anonymous]

I'm kinda racing ahead now and assume that the "PIN" is not stored anywhere and that user is required to enter the "PIN" along with his password.

How about this for auto-tuning:

Choose a fixed set of iterations, the lowest being equal to about 1s of crypto work on a Core2-generation CPU for example. Yes, a current gen CPU will do the work in maybe 0.1s, but remember, 0.1s PBKDF2 is absolutely sufficient with a good password. The highest iteration count of the set coould be something ridiculous like 60s work on a high-end i7.

Engrave that set into an algorithm in VC. Something like 10000 + 10000 * i as you've done with the PIN.

Now, at volume creation time, you evaluate the strength of the user's password. Based on that strength, you pick an iteration count from the set. If the password is super strong, you pick a lower number, if the password is super weak, you pick the highest.

At volume mount time, you calculate with the given password up to the first iteration count and try to mount the container. If it fails, continue calculating to the next iteration count.

This would have the advantage that the iteration count doesn't need to be stored anywhere. VC would have a fixed set of counts and try them in order. The count at which the container succeeds to mount would be determined at volume creation time.

How is that? It would completely eliminate the user's need to deal with iteration counts AT ALL while being auto-tuning to the password strength. For the advanced folk you can always let them pick a custom number from the set.

[Enigma2Illusion]

I prefer Mounir's solution of using the strongest iteration as the default verses your idea for automatically lowering iteration to preset values based on the entropy and length of the password.

Also, multiple attempts to mount the volume using different preset iteration values if the first setting does not work is going to frustrate users with longer delayed mounting times and longer delays for getting an error when they have entered the wrong password since it is a combination of password and iteration setting being correct to mount the volume.

In my opinion, VeraCrypt should default with the highest iteration and allow the user to lower the iterations to fit their mount delay expectations based on the password length. You will have to remember the custom iteration value you used to mount the volume which could have the added benefit of making it harder for someone to brute force mounting the volume since iteration is variable.

https://sourceforge.net/p/veracrypt/discussion/general/thread/09696187/?limit=25#491d

I am not opposed to a future enhancement of VeraCrypt checking the password entropy to guide users to their password strength if it is feasible. But that idea is going off-topic. :)

[Anonymous]

The major "problem" here is that the iteration is not stored. It's a design decision and it's perfectly OK, hence "problem" in quotes.

The key is to design a sane and secure crypto system around that decision. Making the user remember and enter the iteration count or forcing him to wait 60s at boot time is not sane, at all.

The iteration count must be reasonable but first and foremost, by default it must be completely outside the user's responsibility. Forcing a user who can't pick a strong password to remember and enter an additional factor is insane.

The only reasonable course of action is to have a sane default iteration count for when the password is strong and maybe adjust the iteration count when the password is knowingly weak. At no point should the user have to deal with the iteration count if he doesn't care about it.

Ultimately, the password is the user's only responsibility and he must know to pick a strong one. Loading the program with this huge complexity in code and user interaction to protect the user from itself is idiotic. Ideally, the iteration count should be fixed and not even up for debate to this extent.

The "PIN" approach in itself is mind-boggling, let alone the additional confusion caused by calling it "PIN". If the devs can't even deal with a simple thing like the iteration count in a secure and user-friendly manner, I'm very concerned about design decisions deeper inside the product, that have no such apparent effect on the user and were made by the devs without any outside review.

I have never ever seen a crypto system that handled a detail like iteration counts in such an overly convoluted way. Really.

[Mounir IDRASSI]

well...you are missing history here..
VeraCrypt like TrueCrypt has its own internal iterations, outside the reach of the user. And the dynamic mode feature is a facility to give more freedom to those who use strong passwords.

I think you never used TrueCrypt or VeraCrypt and you just arrived here without any background. Please respect the work of the people here and stop attacking for the pleasure of attacking. At no point, you addressed the root questions and at no point you showed any understanding of the need behind this.

Anyway, I'm accustomed to this kind of out-of-scope posts...

[Anonymous]

I never had/have to deal with any iterations in Truecrypt, so I'm not sure what other background you're referring to. Truecrypt was doing it right. You are not.

[Mounir IDRASSI]

Come on...VeraCrypt is based on TrueCrypt, you know that. VeraCrypt increased the iterations used by TrueCrypt (from 1000 to 500000) to enhance security while solving many security issues, and you know that.

And the use of dynamic mode is not mandatory and the usual VeraCrypt behavior will remain the default, and you know that.

So, I'm wondering what is this discussion about. You just want to make noise?
It is amazing how some people are gifted in creating controversy from nothing...please tell me, where did you see that VeraCrypt has changed its default behavior and that now users must deal with iterations? And do you really understand what are we talking about here?

Please, be objective and stop the noise.

[Anonymous]

Whilst I understand what you are trying to do with the high security, I am also disappointed with the long boot time. My fairly recent HP laptop takes 2m30s to boot using AES, whereas with TC it was instantaneous. I'm a mobile insurance guy so my "threat model" is leaving my laptop on a park bench or having it stolen out of my bag, not the NSA trying for 5 years to hack my HD. I just cannot turn up to a customer and wait 2.5mins for my laptop to boot. Unfortunately I have decrypted my drive and uninstalled TC, so now I need to look for something else. I'll keep an eye out for the 32bit bootloader and try again later though because I like the product.

[Mounir IDRASSI]

Thanks for the feedback. The last 1.12-beta version adds the dynamic mode feature that allows specifying lower iterations when password is long enough (20 characters and more). Feedback on this new feature are welcomed.
The 1.12-beta is available here: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds/

[PIK]

Feedback is, it works (?) :)

[Enigma2Illusion]

This is a beta release. If you can test the various changes made to the beta release and provide constructive feedback would be greatly welcomed.

[Anonymous]

Hello,

I am a bit confused about the dynamic mode. What do I need to enter into PIM field to use 100.000 iterations? It is a multiplier, but I can not enter something like 0.25. Thanks

[Mounir IDRASSI]

Hi,

Did you read my post on May 25th 2015 (few posts above) where I introduced the 1.12-beta containing the dynamic mode? I explained the formula used to calculate the iterations from PIM. Here is the link: https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/?limit=25&page=5#9a0a

I reproduce it here:

• For system encryption: Iterations = PIM x 2048
• For non-system encryption and file containers: Iterations = 15000 + (PIM x 1000)

Depending on which case you are, the PIM to have 100000 iterations will be 49 for system encryption and 85 for non-system encryption.

[Anonymous]

I have a problem buying that a dictionary attack would work on say a line borrowed from a song. To my understanding you can't "hash" sections of the password, you have to get all the right words in the right order. Websters dictionary is what? 50000 words is a very conservative guess. Say you get 6 words in, ridiculously high number. Add in the variants with space, underscore, l33t replacements and the fact that the owner might be just as ewll using a different language or misspelled words... I don't buy that any self-respecting brute forcer would bother with that shit. Straight to sequential bruteforcing, UNLESS there is a confirmed "seed". everything else just adds clutter and unless there is a confirmed information regarding a section of the pass or the definate length I don't see how bothering with that stuff in a real life situation would bring you closer to the target faster. Some nerds at a DefCon competition is a academic happening, not a forensic standard.

[Anonymous]

I am a new Veracrypt users that migrated from TC. In the true spirit of TrueCrypt you should aim for 100 % security - no compromises.

If it takes a minute to boot.... so be it. Better than having NSA invading my private life.

Security first, this is what made TC successful. Because they tried their best to make even unlikely assaults fail. Yes, they were paranoid. And as Snowden revealed, rightly so. Being paranoid is an excellent trait for any serious security software developer.

Now... just do everyone a favour developers and inform the users about this in a better way. Preferably in the FAQs and again if you create a encrypted system. That will save you a lot of posts and tickets because waiting for 1 minute after entering the PW makes most people wonder if something is wrong.

32Bit would be awesome. Because yes, a minute is long. But never trade security for speed. Thank you.

I am living in a democracy. (more or less :-P). But there are people on this world whose LIFE DEPENDS ON THIS PIECE OF SOFTWARE! There is no room for compromise. Because this software must withstand the worst attacks from the chinese state security.

It should be noted that most people who are persecuted by their goverment are not encryption or even computer experts. This is why in my opinion it is so important that the software itself aims for maximized security.

Please do not decrease the amount of iterations! If you really want to, at least add an option to maximize them again. Thank you! :-)

[Mounir IDRASSI]

Thank you for sharing your thoughts.

VeraCrypt will always put security first.
As for the amount of iterations, they will not be decreased: the default level will remain high as always and actually it can be increased for those needing extra security through the use of the new PIM field.

[Anonymous]

We were using TrueCrypt, and have tried to use the latest stable version of VeraCrypt on our laptops. However, sitting at "verifying password" for 2 minutes, 51 seconds (I timed this) isn't acceptable. We're not talking cheap laptops either... they are all Core i5's with at least 8GB of RAM and Windows 7 Pro - 64-bit. We're only doing the system partition and not the whole drive, and all of our new laptops use SSD drives.

[Mounir IDRASSI]

Did you use the latest Beta version 1.12? In few posts above, I explained the new dynamic mode feature with the use of PIM field.

The 1.12-BETA is stable for production. I still didn't release it because there is still work on a security feature for protection against evil-maid-attacks.

So, you can use the 1.12 version and specify a small PIM with a strong password, and you can have a quick boot.

If you missed it, the 1.12-BETA is here: https://sourceforge.net/projects/veracrypt/files/VeraCrypt%20Nightly%20Builds

[Anonymous]

When is the official release of the 1.12 version expected?

[Mounir IDRASSI]

The final release was delayed to ensure the best quality possible for the final 1.12.
The remaining feature (protection again evil maid attack) was delayed because of fixing other points, especially the documentation and adjusting PIM use.

The big point now if translations of XML language files. German and French are top priority so if anyone can help on this, it will be much appreciated.

The latest 1.12-BETA is stable (available on Codeplex) is stable: https://veracrypt.codeplex.com/releases/view/616110
Unfortunately Sourceforce is still in maintenance mode so I can't upload new binaries.

Hopefully, if I receive help on translations, I can release final 1.12 on 1st August.

[Anonymous]

I have a short password only 8 signs and the verification needs more than one minute. One till two seconds should be OK.
What must I do if I install the Version 1.12 for getting a faster password verification on my system boot menu? Is it enough to install the new version?

[neotm]

I have a short password only 8 signs and the verification needs more than one minute. One till two seconds should be OK.

What must I do if I install the 1.12 for getting a faster password verification on my system boot menu? Is it enough to install the new version?

[Enigma2Illusion]

Review the documentation on PIM to speed-up your mount time.

https://veracrypt.codeplex.com/wikipage?title=Personal%20Iterations%20Multiplier%20%28PIM%29

[Anonymous]

OK, I use a PIM. But it is slower. I must use the PIM 98 because of my short password.
Did you have any idea how I can make the password verification faster?

[Mounir IDRASSI]

You must use long password in order to be able to use a PIM smaller than 98. Other than that, there is no other way to speedup booting.

[neotm]

OK, now I try a long password with the PIM 1 and now the password verification needs 2 or 3 seconds. That is perfect. But why isn’t it possible to use the PIM 1 with a password length of 6 or 8?
Now I always have the problem that I must reenter the password after the windows login to mount my second disk. I also change the password from the second disk to the same from the system disk. Is it because of the PIM? It would be nice if the password with PIM would save in the cache.

[Anonymous]

A password of length 6 or 8 is not really secure. Your current security actually relies heavily on the iterations number (=high PIM), because with a low one, your password can be easily brute-forced.

[neotm]

For me that is no problem. I want to encrypt my disk only for the case that someone stolen my computer. I will not found all pictures from me and my family in the internet. So a length from 6 to 8 should be enough. For me is also very imported, that the system is useable in a family. That means a password witch everyone in the family knows and which you can enter fast.
Therefore, it would be very nice if you also allow short password and a PIM of one.

[Anonymous]

Thank you very very much!!!!
This PIM thing is exactly the option that was missing imho.
Keep up the great work and excuse my emotional post, which I deleted myself.

Mounir rules!
You made veracrypt the best available encryption software!
(PIM: 1) :D

[Anonymous]

In a properly designed crypto application, you choose your encryption's strength by the strength of the password, and only that.

Here, you have to dick around with iteration counts. And judging by the posts so far, this is going to be a real support nightmare. Good job.

[Mounir IDRASSI]

I agree that the password is the most important part of the encryption strength.
The PIM feature is optional and is not activated by default. it is reserved for advanced users who know what they are doing and even in this case VeraCrypt places limitations to avoid reducing overall security level.

[Mounir IDRASSI]

For those like you annoyed by the extra waiting time, the PIM feature provides an alternative solution: https://veracrypt.codeplex.com/wikipage?title=Personal%20Iterations%20Multiplier%20%28PIM%29

[Anonymous]

Hi, I have a similar problem of long boot on my laptop, but I have to wait more than five minutes before it actually boot this seems overkill.

is it a normal time ?

could I obtain a fastest boot by changing the passphrase and moving my mouse a bit less before encryption or does mouse movement have no effect on boot time ?
\ thanks

[Mounir IDRASSI]

You can obtain obtain a faster boot by setting a small PIM (from 1 onwards) and choosing a long password (at least 20 characters). Once the change done, in the next boot, you'll have to enter the password and the PIM value you have choosen. You can find more explanation here: https://veracrypt.codeplex.com/wikipage?title=Personal%20Iterations%20Multiplier%20%28PIM%29

[Anonymous]

Ok thanks, is there a minimum recommended, I see that truecrypt used only 1000 iterations, something like 20000 is reasonnable ?

[Mounir IDRASSI]

Yes, 20000 is a reasonable choice combined with a strong password.
This corresponds to PIM = 5 for non-system encryption and to PIM = 10 for system encryption.

The recommended iterations in VeraCrypt is the default value associated with an empty PIM. These were chosen to give a good security level in most situations.

[Anonymous]

Will I have to create a new Rescue Disc when changing PIM or does the password still work on the rescue disc (without PIM)? Is there a security risk in using the same password with and without PIM (e.g. on rescue disc and currently in bootloader)?

[Mounir IDRASSI]

It is always important to create a new Rescue Disk when upgrading VeraCrypt on your encrypted system, and it is more important when a new feature like the PIM is introduced.
Thus, you should create a new Rescue Disc especially that you will be using a non empty PIM, otherwise yoou won't be able to boot your system using the Rescue Disk.
As for using the same password with or without PIM, the only risk would come if you use a PIM smaller than the default and your password is not as strong as it should be. Otherwise, you can keep your password and choose a custom PIM value.

[Anonymous]

Mounir, I was one of the many guys that annoyed you because of the long boot time but I keep my promise to donate if you implement an option for fewer iterations. Thank you very much! I hope I won't donate to the NSA though, well you would be incredibly well faked and the fact that you made Veracrypt first unusable for 90% of people with the long boot time is probably the best argument for your authenticity! Which agency would make a software so secure that a lot of their enemies won't use it because it is not usable anymore?

So, finally I come to my question: why is the PIM not secured by **** and shown in clear text in the boot loader? In your documentation you say that in theory the PIM is also an additional safety but that safety is gone if everybody behind me can see the PIM in clear text while entering it, lol.

So it would be nice to change that in a future version.

And I found another "bug": when mounting a volume or device in the VC GUI and you need to type in your PIM, it is a little bit time consuming to enter it. It would be nice to do it like in the boot loader:

1. Type in your password
2. ENTER
3. Type in your PIM or leave the field empty
4. ENTER

If you do not want to do that, it could still be improved. Because now you have to do the following:

1. Mount volume
2. Type in password
3. Click on "Use PIM"
4. Click into the PIM field to be able to write the PIM

Step 4 is not needed, the PIM field should be automatically active to write your PIM into.

But I would still prefer option 1, for users without PIM, pressing ENTER 2 times is not a lot of work but it would make it a lot faster for users with a PIM. Password - ENTER - PIM - ENTER or Password - ENTER - ENTER for no PIM.

What do you think, my most loved french person in history?

Another little bitty bug: if you put a USB hard drive in and the device is auto-mounting, sometimes the password field pops up but the password field is not active so you have to click in it to enter your password. I could not reproduce it every time, sorry for that little information...

[Enigma2Illusion]

Be aware that using Favorites stores the PIM value in the XML file(s) when used for non-system volumes which is necessary to allow for different values.

If Mounir decides to accept your request of using asterisks when the users are entering the PIM value, I would request a checkbox to display the PIM value just like you can for the password.

This would avoid false reports of PIM issues due to keyboard mapping issues or attempting to use the numeric keypad on the right of the keyboard which can result in non-numeric values being input into the field.

[Mounir IDRASSI]

Thank you anonymous for feedback and comments. Since the beginning of the project, I choose to be transparent, public and clear about how VeraCrypt is advancing. I believe that this is important for such kind of software after two year working on this I learned that this approach is also very productive since it make VeraCrypt more close to its community and to the needs to users on the field. The 3 letter entities are certainly following the project also but with nowadays encryption boom and the democratization of encryption at all levels, the trend can not be stopped nor reversed.

Concerning the PIM, I understand your wish to have it hidden like a password. My approach was that the PIM is something that is not as sensitive as the password and I leaned towards usability rather than making it hidden like the password in the GUI.
To address the need for more protection of this field, I will certainly add an option in the preferences to secure it in the GUI.

Enigma2Illusion requested to add a checkbox in this to make it appear. I'm afraid that this will make the password dialog too much "crowded". There are already so many checkboxes. So, the simplest approach will be to make the PIM visible be default and if the user checks the adequate option in the preferences, it will become secured.

As for the fact that you have to click on "User PIM" to enter it, I will not change this: in the first iteration of PIM development in 1.12-BETA, the PIM field was always available which was handy but this approach proved to be confusing for most users who don't use PIM or don't understand the need to have a PIM.
That's why, after so many BETAs, I came up with this "Use PIM" check box, both in the password dialog and the formatting wizard: it simplified the GUI, it made the usage simpler for "normal" users and at the same time advanced users can use it with a single click.

I understand that this single click is anonying for some users but as with anything else, VeraCrypt must address all common usages and find the right approach that suite most users, with maximum usability. Designing Human interfaces that works is not easy.

Concerning the password focus issue, I'll see if I can make things work better.

Thank you again for sharing your thoughts and for your kind words!

[Anonymous]

Thank you for your detailed answer, I understand the reason behind it now and it's perfectly fine.

But unfortunately I am an annoying little shit so I will have to make another proposal: what about creating a checkbox in the VC preferences to ask automatically for PIM after writing the password and hitting ENTER? This way everybody would be happy and beginners are not confused.

But I understand if you don't want to implement it because there are more important things to do. Good night!

[Anonymous]

Thank you for your detailed answer, I understand the reason behind it now and it's perfectly fine.

But unfortunately I am an annoying little shit so I will have to make another proposal: what about creating a checkbox in the VC preferences to ask automatically for PIM after writing the password and hitting ENTER? This way everybody would be happy and beginners are not confused.

But I understand if you don't want to implement it because there are more important things to do. Good night!

[Mounir IDRASSI]

Thank you for your proposal but for now I consider the current PIM approach in GUI the best one and as you said, other more important points need to be dealt with before.

[Anonymous]

How is the PIM handled when the password is cached? When a custom PIM value is provided during pre-boot authentication, is that value cached along with the password to auto-mount Favorties/System Favorites? If not, what exactly happens.. do the favorites/system favorites always need default PIM to get auto-mounted using the password cache? Sorry I have not upgraded to VeraCrypt yet, else I would have tested this and answered my own questions. The documentation isn't clear on caching of the PIM and I'm trying to decide if I want to upgrade or go with another solution.

In my opinion, the minimum PIM value should be determined by the overall strength of the given password, not just by length alone. A standard algorithm for password strength could be created given its content of symbols, capital letters, numbers, dictionary words, patterns, along with length. Given a password's strength value, a minimum allowable PIM value could be determined. Perhaps you could even make this the default. Then if anyone complains of long boot times, just tell them to use a strong password and it will be fast. How it is now, a 20 character password of all A's can have a PIM of 1, while a 19 character password of random characters and symbols requires a 30 sec boot time. Does that make sense?

[Mounir IDRASSI]

The PIM is never cached. That's why in the new VeraCrypt version, a PIM field was added to the favortie and system favorite organizing dialog so that the user tell VeraCrypt what PIM to use for every favorite or system favorite.

Concerning the PIM determination algorithm, this idea was proposed before. I opeted for a simpler and safer approach where the responsability of the PIM choice is on the user shoulder. Also, this avoid developing an algorithm that could prove wrong or unsafe with time and which would require changing the implementation again in few years. The current approach can live on for many years since users can adjust their security level if any breakthrough happens in the future without needing any VeraCrypt upgrade.

[Anonymous]

Mounir IDRASSI : Hey bro 10PIM for system encryption is safe or not if passowlrd is more 20 character???
thx answer

[Mounir IDRASSI]

10 as PIM is a little bit low in my opinion (20480 iterations) but it can be considered safe if and only if your password is strong (at least 100 bit of entropy): this means not only more than 20 characters but also it should be as random as possible and containing a mix of letters, digits and symbols. You can use methods like Diceware (http://world.std.com/~reinhold/diceware.html) or you can just train your memory (http://www.wired.com/2014/07/how-to-teach-humans-to-remember-really-complex-passwords/).

In my opinion, a good tradeoff is a PIM around 50: this give the recommended iterations count for nowadays (~100000 iterations) and it divides the boot time by two compared to the default VeraCrypt level.

[Anonymous]

Regarding the "Ignore the detractors" cmments- That's a great way to make sure the masses use something else. No business that ignores its customers will be successful.

I have tested this product, and I am very hopeful I'll be able to use it, but a 1:30 to 2:00 minute startup, prior to then STILL having to wait for the boot process to enter a windows password, and then wait some more for the profile to load up, is not a realistic expection of users' patience. They will demand something faster, at which point we'll just end up using bitlocker, which is good enough to be compliant and also "free," at least in the sense that they already need Windows Pro and it's included.

[Sebastian Straub]

This boot time issue obviously has caused a lot of annoyance among former TrueCrypt users and the way I see it, it would have been a wiser choice to enable strong crypto by default, but to allow users to actively choose weak crypto if that's what they most desire.

There are good reasons for this massive increase in iteration count, but the current approach is not a sustainable solution, because the challenge that has to be solved cannot be parallelized. In the time it took CPU manufacturers to double single-threaded performance, the parallel processing performance has increased by several orders of magnitude. The numbers are even worse when it comes to FPGAs that solve hashes like SHA-256, especially since bitcoin prices have gone through the roof. So, while our home user is ever bound by the performance of a single core of her CPU, the attackers can make use of ever more sophisticated hardware that can solve billions of hashes in parallel. A new 32 bit boot loader will not solve any of these issues, it'll just give us a one-time performance boost that will be eaten away in no time.

Having a high iteration count definitely makes it harder for the attacker to guess passwords, but it is irrelevant whether a single password can be tested in parallel or not - that's the nature of brute forcing. This problem will get even worse, when attackers get more sophisticated FPGAs and users are still bound by the performance of a single CPU core. Sure, today two minutes are annoying, but in ten years we are going to stare at "verifying password..." for two hours, if we want to keep up with cracking hardware.

The solution is to throw everything a modern CPU - and at some point a GPU - has to calculate as many iterations as possible in parallel. This will allow us to massively increase the iteration count while at the same time decreasing the computation time and reducing the hardware gap between user and attacker. Here's how it works:

• hash the password once, call this value h0
• generate a sufficiently large number of tasks (may depend on the PIM).
• For each task t in the list of tasks:
  • Concatenate h0 with the list index of t and hash it. This will generate a value h1 that is different for every task.
  • Continue with h1 to calculate a fixed amount of hashing rounds (e.g. 1024)
• When all tasks are finished, concatenate the results of all tasks (in list order) and generate the final hash which will unlock the volume.

The cost to calculate the initial and final hash is negligible, but each task will take a few milliseconds and there will be lots of them. As there are no dependencies between each task, they can be processed in parallel and by increasing the number of tasks rather than the iteration count of each process, we will be ready for GPUs with thousands of streaming processors.

How do we fit all this in the boot loader? Well, not at all... As already suggested in a different topic, we are going to need a separate partition that contains a minimal linux-ish environment that solves the whole mess with keyboard layouts and allows full access to CPU and GPU.

If we don't want to break backwards compatibility, we could calculate the hash using the new parallel algorithm first and when this fails, fall back to the old single-threaded one. If the single-threaded algorithm works, we could offer the user to upgrade to the new method...

So, what do you think?

[Von]

I agree with Sebastian.

Here is a quick example, I used AES(Serpent) with a password of over 20 char, left the PIM as default, and used SHA251. The full system decryption process felt like forever (but in reality over a minute) on a very powerful system (i7 6700HQ CPU using an SSD and 16GB of RAM.) This is not ideal. It is not acceptable.

Point 1:
We all know that the password is the most important element here. The software has to adapt and react to that password strength accordingly. If a user chooses a 1 char password, the number of iterations, the methods of encryption used, PIMs, the number of iterations, hashes, and all other security aspects are rendered essentially useless.

Point 2:
Password length alone is not a deciding factor. A user can use 20 letter A as a password. It is the complexity and randomness that matters, and this is something the software should be able to know and behave on accordingly.

Point 3:
In my opinion, being able to use Keyfiles with full system encryption would result in a far more powerful security system than 10 million iterations besides that huge boot-time. I don’t know why keyfiles are not supported or how difficult they are to implement for full disk encryption, but I would put a lot more efforts into a 2-way authentication system to work rather than items like PIMs, iterations or even encryption algorithm support. Remember, a strong, random, effective password with Keyfiles would go a very long way in terms of brute-forcing and many other attacks. Having the user to insert a keyfile through a USB key during boot time would be a very powerful addition to Veracrypt, while decreasing boot time significantly.

Point 4:
We must agree that, regardless of all factors, the boot time with full disk encryption should not take more than a specific number of seconds. For websites, 5 seconds wait is considered border-line too long, and that is when users will start thinking the site is down and move on. What is that value for this case? In my opinion, it should not be more than 10-15 seconds.

Point 5:
Who are we trying to protect our drive against? Is it the typical thief who just wants the monetary value of the hardware, is it business competitors, or is it governmental agencies that have almost endless resources? If this software is designed for the latter, then believe me it would be far easier for them to use other techniques than sitting and waiting for that bruteforce or direct attack on Veracrypt to work. Other means will be used first, including social engineering, key logging, cameras, and so on. So how much paranoia and number of iterations should we really be considering? Really, what is the difference between 1000 vs 100,000 iterations if the password is really strong, or if keyfiles are used?

99.9% of all attacks against SSL are not towards the encryption methods used. They are against what happens right before the connection is made, man in the middle attacks, or by bypassing the entire SSL mechanism (meaning stealing the credentials for example). The point being, using or making the most secure encryption software out there should not be the sole and only goal, but rather all other factors should be considered as well: waiting times, keyfiles at boot, or other alternatives that increase the security of the system without compromising waiting time or requiring heavy resources. Most thieves don’t use the front door, so putting the best and most advanced lock in the world on it should not be the only factor. With these iterations, we are making the strongest lock possible and that is only a fraction of the entire security of Veracrypt.

Deciding what is reasonable, against who, system resources required, waiting time required, how secure the software is, are all factors that should be considered when making decisions.

[Anonymous]

Regarding Point 5: Who are we trying to protect our drive against?
With VeraCrypt I'm not able to decide that question for myself (and in my case the answer would not be "government agency").
I need a tool, not a nanny, so even though I really appreciate the improvements over TC, I'll have to stick to TC for now and hope for some more flexibility with VC in the future...

[Von]

I tried with a 22+ char password and a PIM of 10, with AES and the boot time was less than 10 seconds. Still, I dont need to read for hours about all this before being able to use the software.

[mike rodent]

Haven't read all 9 pages and I have a fast machine.

Personally I think it is quite wrong to deny users of older, slower machines the benefits of Veracrypt (minus the one benefit of iterating through the different encrypts). If a mount time is more than one minute people are just not going to use it.

This sort of fascism of insisting that half the world's population (using recycled comps from 5 or 10 years ago) must do without open source software goes completely against the grain of the open source philosophy, and puts me in mind of nothing so much as the "philosophy" of certain publishers of proprietary OSs.

The obvious answer is surely a fork? I haven't looked at the source code, and assuming it is in C would be a bit tricky for me to tackle personally, but it can't surely be that difficult to identify the iteration in question. Can't someone in a Developing country (or a good soul anywhere) rustle something up along these lines?

[Roger Dane]

WOW.. so I was seeing login times of over 6 minutes (actually clocked 6:35 before just shutting it down). Read this thread. Used a 20 character (Upper, lower, numbers, special characters, no words, no names - which is a standard for our company but often only 12 characters) and a two number PIM.
So next login was 43 seconds! That is amazing.
MAY I SUGGEST a simple "business persons" guide to setting up/using Veracrypt. Make it simple. Steps are fine... but I noted that there are a lot of extraneous commentary in some of the current instructions (yes, pertains to Veracrypt but lengthens, makes more complex the 'use') and a streamlined 'set of instructions' would be beneficial to business / company users (admins). And ESPECIALLY that part about the use of a PIM in SPEEDING UP login... a real gem.
Now we can proceed. Thank you

[murphy]

Just like Mike Rodent – whom I second – I haven't read all 9 pages, and I have a fast machine. ;)

Anyhow, just like him I'd like to add my personal 2 cents by summing up some thoughts I already stated in another thread in a more verbose manner. Pretty sure most of them have been mentioned before, but ... see above. Now in short:

• several aspects of the current implementation are nothing but user harassment, causing unnecessary usability hassle forcing users with "inexcessive" security demands to use less secure alternatives or no encryption at all
• particularly making the required minimum PIM number dependant solely on the password length is just hypocritical and close to nonsense
• password length alone barely is a security factor anyway, you can easily generate 8 character passwords that are a billion times more secure than a password like 12345678901234567890 or even just 00000000000000000000
• what really would make at least a little sense is to implement a rudimentary password security level check algorithm and bind the lowest possible PIM value to its result
• every single user is not only reponsible, but also deciding for the actual level of security on their own – there are thousands of ways to use VeraCrypt in an irresponsible way (like storing plain text passwords in obvious places) which can't be avoided by the software at all
• anyone who really needs an extreme security level is still able to realize it by using strong passwords and/or very high PIMs, no matter how low the minimum requirements for PIM or password length are established

Apart from that, all of the above just unnecessary ... no one except the user himself knows anything about the security level he really needs, and most of those who are using software like TC, VC and the like actually DO know – otherwise they wouldn't use it at all. Trying to make the world a better place by imposing personal standards on others is doomed to failure and will only result in just the opposite effect.

Please enable lower PIM values for medium security level passwords (e.g. 8 characters consisting of upper/lower case letters and numbers ... just a personal suggestion, no absolute standard) to make VeraCrypt a usable tool for people with reasonable requirements like
"I just don't want XY to see my private photos and tax returns."

This shouldn't be too hard to understand, don't you think?
We aren't all terrorists hiding away from the CIA, you know.

[Oliver Parke-Gailey]

I agree with Murphy above.

I am very impressed with VeraCrypt and really appreciate that you guys have gone to this much effort to keep TC / open source encryption alive.

However, I just can't bring myself to use VC full drive encryption on mine or my users laptops while it takes 1m35s to 'unlock' before windows even starts to boot. (with a password less than 20 characters that is).

I really do think there is a case for making the PIM optional and allowing for full drive encryption with 'weaker' passwords (ie. 8 characters) for people who simply need medium level security for their drives. People, as Murphy described, who simply want full drive encryption to keep their laptops secure from theives and nosey friends from looking at tax returns.

Please think about making this happen in a future update. I'm still on TC 7.1a and looking for a suitable replacement.

[Andreas Boehlk]

I personally do not agree at all.
A "password" with 8 characters is no password, but a joke. In case of a person using such a "password" I can see not reason of using an encryption software at all.
Veracrypt is not a low end encryption tool, but has its place in upper reagions.
If You ever tried a product (payed) from that part of the scale and offer it an 8 character "PW", it will either reject You or demand a second verification item.
Gladly Veracrypt is so sophisticated that it prevents You from undergoing a mistake and get an unreliable encryption by spinning up the iterations. Bad (no) PW --> long waiting time but nevertheless good security.
So we agree to using areal PW > 20 characters. When using an old PC I had system boot up times wit a short PW and a low 3 digits PIM of over 8 minutes. Then I changed it to a good PW with a just 2 digits PIM and the time to boot start is 8 seconds; I can live with that. You can even set the PIM to 1 and You wait less than 2 seconds.
I can not see anything wrong with that behaviour and I hope that Mounir and his team will stick to their idea of security, cause I do not want to see a newspaper headline telling us that a VC protected volume is hacked
And I can only advise anyone with the idea of weakening the security standards of Veracrypt to play with other tools or save their time and ours and stop using encryption.
Even though I do not agree with Murphy in most of his points, I like his idea of calculating the strength of a PW by better criteria than only its length, but it is better than no score for the PW quality. There is now a routine in the code that relates the PIM range to the PW quality. Next step could be a better score calculation for the PW.

Andreas

P.S. Thanks to Mounir for his great work!

[murphy]

[reposted below for reasons of continuity]

[darius80]

Try new VeraCrypt version 1.17 because
* Cut mount/boot time by half thanks to a clever optimization of key derivation (found by Xavier de Carné de Carnavalet)

[eugenesv]

@Andreas Boehlk
What I don't understand if why you're forcing your views on others. Given that you are free to se up security strength as high as you like, how exactly does it affect YOU if other users adhere to lower standards? Say, that dreaded headline appears. So what?

[Andreas Boehlk]

Sorry eugensv, I cannot see any forcing of my views on others. I just tried and wanted to protect Mounir's inredible good work against attempts to persuade him to weaken this really good security software.
I consider my statements to be widely spread in security circles and my conclusions make up my opinion and I stick to them. That is freedom of expression and it becomes more and more important nowadays.
Kind regards
Andreas

[biztastic]

Mine has been loading 10 minutes.
I have a 20 character password and my PIM is 4 digits

I would like to use my PC today

[Enigma2Illusion]

Please read the documentation regarding the PIM and the calculations.

https://veracrypt.codeplex.com/wikipage?title=Personal%20Iterations%20Multiplier%20%28PIM%29

NOTE: The program's default iterations may not be the same as PIM iteration calculations.

For system encryption, the program default is 200000 iterations using the SHA-256 hash or 327661 iterations using HMAC-RIPEMD-160 and the user minimum PIM value when password is less than 20 characters is 98 which is 200704.

https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation

For non-system encryption, the program default is 500000 or PIM value of 485.

Setting the PIM to extremely high value will cause very excessive wait times for the mount operations.

[biztastic]

Ok. Thanks
I didn't know at first that PIM is some kind of multiplier, I thought it was just like a secondary password so I set 4 numbers which was too many lol. reduced it to 1 and it is much better.

[murphy]

That's why it was renamed from PIN (Personal Iteration Number) to PIM (Personal Iteration Multiplier) ... which is, however, certainly not self-explanatory ;)

[murphy]

Hi Andreas,

unfortunately you didn't assimilate the information in my post before reacting to it, forcing(!) me to elaborate again on what I've expleained before in detail already. I'll slice your verbiage into parts, for even better transparency this time:

1. "A password with 8 characters is no password, but a joke."
   From the perspective of cryptography, this statement itself is a joke. Heard of information entropy before? Paragraph you missed: "password length alone barely is a security factor anyway, you can easily generate 8 character passwords that are a billion times more secure than a password like 12345678901234567890 or even just 00000000000000000000" ... now please explain how 12345678901234567890 is a more secure password than $4n&yC2m for example?
2. "In case of a person using such a password I can see not reason of using an encryption software at all."
   Thinking of 4 digit PINs for ATM cards and the like, I cannot see the slightest sense in that sentence at all ... and therefore won't respond to it at all.
3. "Veracrypt is not a low end encryption tool, but has its place in upper reagions."
   You are missing out on the subject here. We're not talking about the tool, but about the usage of that tool. And that alone is where the security lies in, as comprehensibly clarified above – paragraph you missed: "every single user is not only reponsible, but also deciding for the actual level of security on their own – there are thousands of ways to use VeraCrypt in an irresponsible way (like storing plain text passwords in obvious places) which can't be avoided by the software at all"
4. "If You ever tried a product (payed) from that part of the scale and offer it an 8 character "PW", it will either reject You or demand a second verification item."
   No, it won't. It will reject your password if it isn't safe enough, which has little to do with the length of it alone. See above.
5. "So we agree to using areal PW > 20 characters."
   No, we don't. As obviously demonstrated by the thoughts given on it, given by myself and others. Paragraph you missed: "anyone who really needs an extreme security level is still able to realize it by using strong passwords and/or very high PIMs, no matter how low the minimum requirements for PIM or password length are established"
6. "I do not want to see a newspaper headline telling us that a VC protected volume is hacked"
   Then you need to learn about encryption basics to understand why this will never happen, even if (complex) 8+ character passwords with a PIM of 1 are allowed.
7. "I can only advise anyone with the idea of weakening the security standards of Veracrypt ..." – Which is who? Due to which statement exactly? – "... to play with other tools or save their time and ours and stop using encryption."
   According to that nonsense, you cold also stop using
   a) the aforenamed PINs on ATM cards
   b) keyless entry door locks with personalized codes
   c) engine immobilizers using keypads
   d) activation codes on all kind of services like prepaid cards
   e) TANs for online banking transaction authentications
   f) – ?) countless further examples I can't even think of right now.
8. "Even though I do not agree with Murphy in most of his points, ..."
   Now that you've re-read them, which ones exactly (please cite word by word to avoid confusion again), and for what factual reasons exactly?
9. "... I like his idea of calculating the strength of a PW by better criteria than only its length, but it is better than no score for the PW quality."
   Hooray, we got a concensus! At least partially, as the assumption that longer passwords (which have to be kept simple, to be able to remember them) generally score higher than shorter passwords (which can be more complex but still remembarable at the same time) is still questionable at best, but I'll leave it at that.

Talking of steps ...
1st: understanding why complex passwords are better than just long passwords (done ... sort of)
2nd: understanding why security doesn't derive from a tool alone, but mostly from the responsible handling of that tool (an unexpected challenge, apparently)
3rd: understanding that all of us want the same thing in the end for ourselves – which is a level of security that we personally need

Forcing personal needs on others without any given reason is as pointless as futile.

To finish it off, I'll quote Mounir from one of his earlier statements posted on 2015-03-02 that I just happened to come across:
"Indeed, adding a better password strength evaluation function is an important feature. This will make VeraCrypt more modern as this type of strength evaluation is now mainstream."

Having that cited, utterances like
"I just tried and wanted to protect Mounir's inredible good work against attempts to persuade him to weaken this really good security software"
are outright ridiculous considering what I've actually said before, and apogees of pretentiousness like
"I consider my statements to be widely spread in security circles and my conclusions make up my opinion and I stick to them."
are as laughable (considering de facto conventions that truly exist in security circles) as counterproductive (considering that sticking to opinions is clearly no sign of expertise ... the opposite is).

Thanks to Oliver Parke-Gailey, who has proven to be supportive in regards to actual improvements of the product, and eugenesv, for sharing the idea that applied levels of security are solely a concern of the user, but not the developer.

Without any doubt, almost anyone on this thread – including myself – is highly appreciating Mounir's accomplishments. We just don't feel like having to boast about it in order to compensate the lack of other qualities.

Most of those who are criticizing the tool are thereby showing that they really want to use the tool. It just needs a bit of refinement in the usibility department, as earlier confirmed by the developer already.

Mindless adulation, however, leads us to nowhere good.

[lordconrad]

VeraCrypt is ridiculous. I’m only worried about stolen hardware, not being hacked by a government.

I’m sticking with Apple FileVault on my MacBook and TrueCrypt on my USB key.

You should have a "VeraCrypt Light" or "VeraCrypt SE" where the number of iterations is hardcoded to 5000. This would offer plenty of speed, not require a custom PIM to be entered every time, and still be 5x more secure than TrueCrypt. Most people aren't worried about governments, just protecting their data incase their computer is stolen.

I also use TrueCrypt to access encrypted files on mobile devices, which puts VeraCrypt in an even worse position (speed-wise) due to the fact that mobile devices have slower processors than PCs.

[murphy]

Thanks for your support in the sense of promoting a minimum of basic common sense.

[MartinB.]

Hello,

first of all I want to say that I am very happy that there is a successor of truecrypt. Thank you!

A few weeks ago there was a interesting article about veracrypt in the german magazine c't. After reading I tried veracrypt because I am looking for a full disk encryption software for quite some time. I am the administrator of approximately 60 laptops in a medium sized company and we do not use encryption at all today. Veractypt seemed to be the perfect solution for us.

But after installing I could not beleave the long boot time (~60 seconds an a Thinkpad T530). A google search brought me here and I went through the discussion. First I want to say that I am perfectly fine with the idea of making the software as secure as it can be. The default values should be chosen that it fits your long year experience in security. But for some szenarios it would be great to have the option to increase boot time by choosing a low PIM in combimation with a medium password.

Personally I don't have a problem with typing a 20+ character password every morning (and evening after switching to home office) but I can not force my users to do this. Long boot times are not an option as well. We are happy that we decreased them by installing ssd's. In times of "instant on" devices like iPads its simply not accepted by users anymore.

Another point I want to make is this: The encryption don't have to resist 10 years in my case because our business laptops are replaced every 3-4 years.

So until now I don't think we will encrypt our laptops which means leaving them fully vulnerable.

I can imagine that there are many cases like mine so please think about this again.

Thanks a lot and keep up the good work!

Martin

[murphy]

The encryption don't have to resist 10 years in my case because our business laptops are replaced every 3-4 years.

:D

I know this wasn't meant in a funny way, but finally you brought a bit of humor in this thread. At least I had to laugh, although it was a bitter laugh ... because the ugly truth is:

This won't happen. Ever.

Believe me, I've been following this mess on this and other VeraCrypt discussion sites for years – don't waste your time, get on and keep in search of alternatives.

Best of luck!

[IronFox]

The truth of the matter is that the kind of passwords that humans can easily memorize don't have much of a place in offline attackable encryption. I found a fair solution are cryptographically secure random generated character sequences stored on a physically triggered keyboard playback usb stick or the likes.
Trying to compensate weak passwords by linearly scaling the cost of decryption tests is based on the assumption that end user computation power scales at the same pace as super computer capacity. It does not.
Unless I completely missed the aim here, the used mechanisms scales linearly regardless of password length, whereas password strength itself would increase exponentially with its length. Each new character increases memory and computation costs by a constant degree, while scaling the effort necessary to crack it by a factor equal to the number of possible characters used by the generator.
And yet, rather than trying to educate users of good passwords, and getting them away from manually typing them in, veracrypt generally assumes that all passwords are weak, and introduces rediculous and unnecessary boot delays and configuration complexity.
I would reconsider your philosophy.

[ilsa]

I found this thread while trying to figure out why it takes VeraCrypt a full 2 minutes to boot on brand new i5-T460s laptops /w SSD drives.

So apparently not only is this expected, but people like Andreas pompously believe that this is how it should be and what they say goes and everyone else can go screw themselves if they don't agree.

I just wanted to give my 2 cents and say that it doesn't matter how good VeraCrypt is if it's such an inconvenience that nobody is willing to use it. This is 2017, not 1990. A 2 minute bootup time is unacceptable. PERIOD. This is especially frustrating if your computer is forcibly rebooted (while you were in the middle of working) by Windows in order to apply one of it's constant stream of updates.

This has now put our encryption rollout on hold because I am not willing to inflict such an inconvenience upon the users I manage. Since the people here seem to think that a common business user needs a level of encryption that James Bond would whistle at, we may well have to abandon VeraCrypt entirely.

So well done Andreas and others who think like him. You get your absurdly strong encryption. You have also successfully alienated who knows how many people and obliterated any relevance that VeraCrypt was hoping to achieve. Congratulations!

[Alex]

Hi ilsa,

You can change password and pim at the boot password prompt. (F2 key)

Also you can separate keys and data encrypted. (put keys on external USB)

Also there is possibility to use two factors authorization.

All above are possible for EFI boot computers.

[Sebboost]

Hello.
For non-system volume in Windows you can specify your default PKCS-5 PRF. Indeed, if you choose auto detection, veracypt try all hash type for test password.
For set default PKCS-5 PRF edit "C:\Users\%USERNAME%\AppData\Roaming\VeraCrypt\Configuration.xml" (before mount volume). I want set HMAC-SHA-512, I set line <config key="DefaultPRF">1</config> (1 for HMAC-SHA-512).
After, Veracrypt gui display default PKCS-5 PRF to HMAC-SHA-512.

[Macker]

Sadly, initial excitement at this product was changed by frustration at such long boot times. I am currently unencrypting my drive and uninstallling VeraCrypt. This is a non-starter for the average person. What a shame.

[murphy]

Why don't you just use TrueCrypt Format to encrypt your drive and then VeraCrypt to access it?

The possible security issues due to discontinued development are only related to the TrueCrypt application, not to the encryption provided by TrueCrypt Format. It basically just doesn't use those stupidly high iteration numbers.

I'm using four TrueCrypt formatted partitions with VeraCrypt, and they're mounting within one or two seconds altogether. The only thing is you have to be careful not to change the volume password with VeraCrypt, because then it converts the volume to VeraCrypt format without any warning ... apart from that there aren't any downsides.

[Mark]

Hi,

This is my first post so I'd like to say thank you to Mounir for his work on this project, it's much appreciated.

Back in 2014 on page 1 of this thread​ Mounir mentions that boot time password verification would be faster with a 32 bit bootloader.
Has that been done? I don't see it mentioned in the release notes, or in the source forge tickets. I've not read every page of this thread, but I've searched it.

Cheers,
Mark

[Anon]

Made a user solely so I could add my frustration here as well. I was also very surprised to learn about the bizarrely long decrypt times. Unfortunately, today I had to spend time debugging some GPU driver, requring me to restart maybe 100 times. Needless to say, I was not at all thrilled to have to spend so much time pointlessly waiting for the boot decrypt.

I will be formatting this system, reinstalling the OS and then using a TrueCrypt encryption with VC. Is that enough or do I have to install TC instead? I have some other partitions with TC encryption, so that would be alright but very silly.

Convenience is the most important thing for spreading encryption more widely. To insist that users should use unnecessary and coounter-convenient features is very poor software design.

[murphy]

As said above:

just use TrueCrypt Format to encrypt your drive and then VeraCrypt to access it

i.e. "TrueCrypt Format.exe" of the last full-functional TC version 7.1a
and "VeraCrypt.exe" of - AFAIK - any installed or portable VC version

So the answer to your question is: No, you don't need to install TC, but (usually) you need to obtain the full package to get TC Format, if you don't have it already. Just look for the portable download.
Please also note my warning regarding volume password changes with VC in this context.

Have fun with partitions mounting in tenths of a second!

[Christopher Schultz]

Could a simple "VeraCrypt is busy trying algorithm [alg]..." and maybe a slow spinner like "|/-\|-/" to show that the machine is not frozen? I'm evaluating VeraCrypt in a virtual machine and it looks completely frozen. If I enter the wrong password (which happens from time to time), I can't tell if VeraCrypt has crashed, decided my password is bad and refused to boot, or is still working away...

[Ross J]

If you want to reduce the boot time, just specify a lower PIM value. Lower PIM value = faster boot at the cost of reduced security. You can try different PIM values until you find the balance of speed vs. security that works for you. (Note that Veracrypt will ignore the specified PIM value if the password is shorter than 20 characters, but you really should be using a strong password anyway.)

The setting already exists - maybe the Volume Creation wizard could guide the user to setting an appropriate value? The "Volume PIM" screen has a lot of info on it, but users never read the text. It might be possible to redesign the screen to make it more intuiative.

[murphy]

Either you haven't read the thread you were replying to or you just failed to understand what it's all about in the first place. Most of us already know about the "news" you were trying to provide, but unfortunately the named setting is exactly the problem ...

I'll qoute myself (again):

Paragraph you missed: "password length alone barely is a security factor anyway, you can easily generate 8 character passwords that are a billion times more secure than a password like 12345678901234567890 or even just 00000000000000000000" ... now please explain how 12345678901234567890 is a more secure password than $4n&yC2m for example?

"$4n&yC2m" IS a strong password.
"00000000000000000000" IS *NOT* a strong password.

Again, the problem with VeraCrypt is
a) that you're only allowed to reduce the PIM when using reeeaaally long passwords, and
b) that password length is really not the primary factor of password strength. Complexity is.

In response to that issue, a long time ago Mounir promised to look into that matter, as he acknowledged there are by far better methods to determine password strength than relying on password length.

But alas – to my current knowledge – this hasn't changed to date.
(Someone please correct me if I'm mistaken, if so I'd like to know.)

Therefore the only option to significantly reduce mount times still is to use "TrueCrypt Format.exe" ... as stated multiple times above.

Aside from that, your suggestions on GUI improvements are of course very welcome (but, in this case, have also been discussed already IIRC). However, nobody of relevance will read them in this thread anyway ;)

[Andreas Boehlk]

Hello murphy,

Your correct statement:

"$4n&yC2m" IS a strong password.
"00000000000000000000" IS NOT a strong password.

is not relevant. The point is, that a strong password costs more time to calculate it for cracking purposes.
But by design it is not possible to calculate VCs password; the only possible cracking method is brute force and the main time demanding factor for this method is the length of the PW.
I personally prefer a strong PW core (10 characters generated by a personal sentence) and then lengthen it by padding with more than 10 keystrokes.
So Mounir is perfectly right in demanding 20 characters.

Andreas

[murphy]

I wasn't referring to calculating passwords, but indeed to brute force attacks.
But to reasonably intelligent attack methods, not to completely stupid ones ...
Meaning, those including dictionaries and standard numerical sequences,
like the ones I've given as examples above.
Which is the reason why those are excluded by many pwd setting routines.

So Mounir was perfectly right in admitting the following (quoting myself again):

In response to that issue, a long time ago Mounir promised to look into that matter, as he acknowledged there are by far better methods to determine password strength than relying on password length.

Can't link the post because I forgot where it was ... maybe even in this very thread.

//EDIT to clairfy:
In the strict sense of the word, simple brute force attacks do not include any intelligence.
So in fact I was referring to intelligent attack methods that also include pure brute force.

//EDIT to elaborate:

Note, a brute force attack may not necessarily try all options in sequential order. An advanced brute force attack may make certain assumptions, e.g., complexity rules require uppercase, first character more likely to be upper than lower case).

(quote from stackexchange)
So "advanced brute force" seems to describe best what I'm talking about.

[karatchov]

I came here hoping to find an explanation of why it takes more than 1 minute to boot a system enrcypted Windows 7, that used to boot in about 7 seconds.

And to be honest, I'm dumbfounded.

YES..., I know ..., it is probably a weak defence to use short passwords with a low PIM, but why FORCE it ?

Everybody can have a different use case.

I'll be more than happy to read/accept few dialogs/warnings telling me how stupid I am, or how I'm gonna shoot my self in the foot, or how my computer will explode unexpectdly, or how my data will end up shared all over the internet.

I'm TOTALLY AWARE of why it can be a bad/very_bad idea, but I'm TOTALLY OKAY with the compromise.

Why do you need to force a "non-joke" password ?
There are hundreds other ways to misuse this tool and end up miserepresenting Encryption and Veracrypt by a stupid user.

My use case:
- I just need a very simple protection from the common thief.
- I probably wouldnt care much if a thief decrypted my data.
- If somebody/some entity have enough will power to try decrypt my "really bad, 4 digts" password, I'm sure it can have much easier way to all my data.

I think for now I'll remove VC, and go back to the realms of the unprotected.

On the other hand, I really urge the devs of VC to re-think their decision.

[Alex]

It is possible to change password and PIM in login prompt of pre-boot. Enter password and press <F2> You can select any pwd and pim.

[karatchov]

Thank you for the reply !
I'm not sure how to do that.
I tried with the latest versions: v1.21 and v1.22b4, and couldnt change the password., even with various settings.
<F2> had no effect.
The usual password change using the GUI after the system booted had the usual absurd requirments.

[Alex]

The solution is UEFI boot only.
MBR version is very limited.(size of boot loader ~32KB)

[karatchov]

Thats unfortunate for me,
If it is already implemented in the UEFI bootloader, why not add the option to the GUI with an extra warning ?

[Alex]

It is added to the fork.
https://sourceforge.net/projects/dc5/files/beta/
DCS-2017_03_28.zip

[karatchov]

OK, I see
-When using "VeraCrypt Setup 1.20-BETA2p2.exe" from that package, you can use a short password with a low PIM. or you can change the password later without any restriction (just a warning)
-you can upgrade later to newer VC versions (i tried 1.22beta4), the bootloader get updated too, and you keep the old password :D

And the computer boots fast now :D
I think thats worht the hassle, Thanks a lot !

On a sidenote, can anybody verify that the files shipped with this version (VeraCrypt Setup 1.20-BETA2p2.exe) are originated from VC and properly signed ?

[Alex]

kernel code from 1.20b2 (need to buy key from MS)
User mode code is built with minimal patches listed. Signed by DCS key(it is possible to check because DCS EFI loader is signed this key too)
Note: DCS key is not verified by MS.

[Henry Code]

Hi

I've been using TrueCrypt since 2008. I've tried VeraCrypt for a year or so and after reading this whole thread I'm coming back to TrueCrypt. And I'm not the only one. I've got enough of this crap!

In my personal opinion VeraCrypt's developers obstinacy about ridiculously high security settings is making VeraCrypt completely unusable. It's just like "F#k you dear users - we are security experts and we know better". Since I have one encrypted system partition and another 2 to mount during startup wating 40 seconds to mount each of them is unacceptable for me. I'm not a hacker, journalist, pedophole or a terrorist - just a normal user that cares about security. Developers approach in this case is making far more harm than good to the data security awarness by making it completely unusable to the normal user.

The added PIM feature is even more unusable than very annoying long mount times. It requires user to create 20 character password (which is just ridiculous) and also requires to enter another number in a second input field (which is very inconveinent). If you would really care about security you would just make some simple password quality meter + make for example 3 last password numbers a PIM count. Just that simple...

I certainly prefer to input "BGHj45!@js050" and hit enter (where 50 is a PIM count) rather than enter
"aaaaaaaaaaaaaaaaaa" and after that use a PIM checkbox and enter another "secret number".

I think you are a complete ignorants in the field of proper UX design or even worse - you are just making an inside job to make a good security available only for paranoid computer nerds.

Bye bye VeraCrypt.

[Ville Syrjälä]

I must agree that limiting the options is just plain silly. If someone needs the computer to post faster, but doesn't need his computer to be secure for 100 years of brute forcing, I think it is good to have the option so that he can also use the software. I think from the previous discussion it is clear that VeraCrypt is not secure per se, by giving users options to use non-secure passwords. And this is not a complaint. I appreciate that the user is given a chance to use any password he/she wishes, because it is his choice how secure he wants his encrypted volume to be.

If somebody thinks that it is okay that after 10 years his data is decrypted, why would he give up the usability for the cost of more security than what he needs. Why force the case, while the software can still be used unsecurely in other ways.

I ended up here because I googled why the boot manager was so slow. It's there on the limit if the computer is anymore usable enough for me or not. I'm happy if my data is safe for 3 years. My password is very complex, but not 20 characters long. It is a compromise with security, ease to type it and capability to type it with certain certainty without errors.

I understand with Apple being popular nowadays, that people start to think that forcing people to do things in one way and forcing their behaviour and minds to a certain mold is a good idea. Well, it really is not. History has shown that.

I really appreciate the software though. It is okay for encrypting partitions that are occasionally used. It is just a shame that a promising piece of software is made unusable for so many people by a simple strange fetish.

[raffe]

I agree. I use VeraCrypt on my family's travel computer. We all share the computer, so it is used by children, adults and friends. We use a short password, so it is easy for us and our friends to use the computer, but of course we don't want to wait more than 15 seconds for the computer to start. So we use a short password and low PIM on the computer, even if we know it is not the safest thing to do, but it is safer than nothing (PM me if you want to know how I did it).

It is enough for me to annoy any thief that steal the computer, and to give us about 24 hours to reflect and think about IF there are anything sensitive stuff on the computer (maybe someone is still logged in on their e-mail = we have time to change the password, etc). But we don't have anything other important or "dangerous" on it. And a random thief probably don't know about cracking crypted harddrives, so it will not be cracked right away if ever, they just throw away the harddrive, install a new one and sell the computer to get some easy cash.

[Pinto Buck]

More boot RAM appears to be a solution to the problem of slow password authentication during boot up of Veracrypt system encrypted drives. On computer #1, my 50 character password is authenticated in 4 seconds. On computer #2, my two character password takes over a minute to be authenticated. Both computers are modern and up-to-date.

Computer #1 specs: AMD A12 processor, 8 GB RAM, 1 TB hard drive, Windows 10. Authenticates 50 character password in 4 seconds.

Computer #2 specs: Intel I5 processor, 8 GB RAM, 256 GB SSD drive, Windows 10. Authenticates 2 character password in over 1 minute. Computer #2 is an HP Probook 650 G2.

During boot up, computer #1 Veracrypt uses SHA512 and well drawn characters. Computer #2 Veracrypt only allows SHA256 and displays large, low resolution characters that look like old PCs booting in safe mode. My conclusion is that Veracrypt is not the problem, and the author is correct in his high security approach to encryption. More boot RAM appears to be the solution to fast password authentication.

I have found the Dell and HP computers, with Intel or AMD processors, take about 1 minute to authenticate even 2 character passwords. Conversely, Ausus and Lenovo computers with AMD processors authenticated very long passwords in 4 seconds.

Since computer brand seems to make a difference, it would be helpful if readers will list their type of computer and how quickly it authenticated veracrypt passwords.

Slow 1 minute: New and used Dell and HP computers with Intel or AMD processors, using Windows 10.
Fast 4 seconds: New and used Lenovo and Asus computers with AMD processors, using Windows 10.

[tinchote]

Add me to the list of users who uninstalled VC from several machines for this ridiculous issue. Back to TC.

[Matt Leonard]

From the few messages I read here, there seem to be many different opinions on what is the right balance between security and usability. And a logical conclusion is that the user should have more control of the level of security he wants appears in many posts. I can only disagree.

While I understand that a few years ago, the need to have more options in VeraCrypt could make sense, there are nowadays plenty of encryption softwares users can choose from, that differ in strength and in the way they encrypt data. I think it becomes more important to now maintain a clear image of what VeraCrypt is so that users can easily make their choice in this landscape of many competiting softwares that is likely going to grow bigger in the next years. The reputation of VeraCrypt as a "very strong, multi-platform, partition or full disk encryption tool" would be a good choice of image, both because of its history and because of what other products propose today.

To me, VeraCrypt could really become the equivalent of GnuPG for disk encryption: very secure, for people who have secrets to keep, and with the side effect of being a bit inconvenient to use. And even if GnuPG is not widely used when considering tasks involving the human user (like sending emails, excluding transparent uses like signing Debian packages), it is still there after many years and popular for a community of users. So that's probably a good bet for VeraCrypt.

Thanks to all VeraCrypt developers for their hard work.

[vohzuimgut]

Well, by now you certainly got a reputation of being secure to the point of being impossible to use for normal people. Nobody wants to wait ages for boot-up, and only a few special people are willing to type 20+ character passwords.

Most poeple are not willing to trade convenience for security. Some do trade, but only up to a reasonable point ( https://www.xkcd.com/538/ ), and there's only so much they let you force them to...

[Nikolay]

(sorry for bad english)
Yes, i too should use bitlocker instead VC,
I encrypt only external disk. Protect for: random thief, famuly, friends. (not for FBI or hackers).
VC sometime mount fast (3 sec). But sometime mount 1 minute. (i5-6500, 8gb). If click "automount, then mounting always during 1 minute". 20 length password and i should remind PIM and always enter PIM - this is not usable
May be add options? I wish 5.000 iterations, and store all info in header. (PIM, AES, e.t.c,)
Also i can't use VC for full disk encription. Because this external drive sometime use other persons. And windows offer to formating encrypted disk. High risk to lost data.
I choise bitlocker. Bitlocker have only 2 minuses for me: 1. no options, (some options only in deep windows config, and command line). 2. Bitlocker no have UI for dismount disk.