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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-18
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-19
"Crypto is bypassed, not penetrated"
Shamir's law
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-19
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-19
"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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-20
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-20
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 ??? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-20
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-20
@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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-20
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-21
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-22
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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-24
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
The TC audit suggests:
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.
Shamir's law
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.
"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
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
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:
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.
Freeman / Mrere
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.
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.
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.
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.
Again more made up figures. Lying will not help your case, however it rather helps prove mine.
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
LOL You didn't think I would let you get away with that did you ??? :)
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
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
This leaves room in the future for lower and/or higher editions:
Does the VeraCrypt community have alternate naming nomenclature for the editions?
@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
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?
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.
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.
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.
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.
There is a duplicate and more detailed thread on the VeraCrypt website, so I am ending this one to avoid confusion.... my bad.
Last edit: pjc123 2015-01-24
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:
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:
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.
Thank you Mounir for clarifying your decision. Sorry I misunderstood your previous post. I prefer the approach you are taking of one product version.
Last edit: Enigma2Illusion 2015-01-22
Alright, that sounds great.
Is it planned for the next version to make system partition transformation from TC to VC possible?
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.
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).
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.
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!
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?