This project has moved. For the latest updates, please go here.

User selectable KDF iterations

Topics: Feature Requests
Jan 6, 2015 at 11:17 PM
The mandatory high number of KDF iterations makes the program inconvenient to use, especially on slow-to-medium systems. Please consider to allow a user selectable number of iterations, e.g. by a user-defined parameter in a text file, that will be read upon program invocation.

If a user uses a very strong password, there is no reason to stretch the KDF so much. The default value in the parameter file can be high for the average user, but please let the more advanced user a way to tweak that number.
Jan 7, 2015 at 11:51 AM
The philosophy for any change to VeraCrypt is how does [insert new feature] increase security.

If the feature is one of convenience and has no detrimental effect on security then it is considered on that basis.

However all other requests which directly affect security, such as crippling VeraCrypt's brute force protection, are judged on their contribution to improving security.

As you can see, your request does not add security, it in fact weakens it. Seems like an odd request for a VeraCrypt user to make.

CipherShed may be more suitable for those looking for faster boot times in preference over security.

Personally I prefer security over all else, which is why I am a VeraCrypt user and not a CipherShed user.
Jan 7, 2015 at 12:37 PM
Edited Jan 7, 2015 at 12:38 PM
In real life systems, there is always a tradeoff between usability and features/security.

Just as you don't want to force a user to use a PW of 32 char min length (which certainly makes the system much more secure), but you understand that many would tradeoff that added security for the convenience of a shorter PW, I don't understand the rationale to force the user, who might mount his volume many times a day on a slow system, to wait for the KDF iterations to finish.

From a technical perspective, 500,000 iterations add 19 bit of security to the PW. I rather add 4 more characters to my PW for the same increase in security and get my volume mounted immediately.

I don't suggest to have a low hard-coded iteration count. I suggest that an installation will default to the present value, but one can add a parameter in an ini file to have whatever one fancies, tuning to his specific system performance.
Jan 7, 2015 at 11:01 PM
I think the trade off has already been made, Mounir has coded VeraCrypt with the lowest iteration count he feels safe with.

Please remember VeraCrypt's target user base is mainly "security aware" users, those that value any additional security improvements, however small, over speed.

Deliberately crippling the number of iteration's would be rather like buying a V8 car and removing 2 spark plugs, it doesn't make sense. You may as well buy a cheaper less powerful car to start with.

I understand ChiperShed may have a reduced iteration count option soon, possibly called the "performance" option.

When you are ready for the V8, come back to VeraCrypt :)

Joking aside, I understand your frustration waiting for volumes to open, I do this many times a day. However I understand real security is not "pain free" and I am more confident because of the delay.
Coordinator
Jan 8, 2015 at 9:48 AM
Hi all,

I understand both points of view. Since its birth, the spirit of VeraCrypt is to provide the maximum possible security. With the growing user base, the relatively long time needed to mount the volumes started to appear as an issue for many users. Since then, I regularly explain why this mounting time is needed to give a standard security level to all VeraCrypt volumes.

My personal objective is to offer a security solution that could be used by a large number of users, not only tech-savvy. Reducing the mounting delay will appeal to more people but it can reduce their volumes security. Staying with a long mounting time can make normal users prefer using potentially insecure alternatives.

One possible solution to this dilemma is to introduce a 2-dimensional criteria for security in VeraCrypt based on the couple (password, iterations count).

Today, VeraCrypt security in based on the 1-dimension provided by the password since a static iterations count is used. The password being freely chosen from the user with no limitations, the static count was chosen to offer a fair security for normal passwords.

An evolution can be the activation of a second security dimension by allowing the iterations count to be dynamic but at the same time disallowing it to be below a certain minimal value. In this case, we will add a limitation to the chosen password in order to ensure that it can't be shorter that a certain limit and this limit will be calculate dynamically from the iterations count.

Following this, we can have two security modes:
  1. Static Mode: this is the current mode. A fixed high iterations value is used. The password can have any length.
  2. Dynamic Mode: The iterations count can be defined by the user but always bigger than a minimal value. The password will have minimal requirements that will be dynamically calculated so that the combination (password, iterations count) will always give a security stronger than a predefined minimal limit.
Any thoughts on this?
Thanks.
Jan 8, 2015 at 11:52 AM
idrassi wrote:
Following this, we can have two security modes:
  1. Static Mode: this is the current mode. A fixed high iterations value is used. The password can have any length.
  2. Dynamic Mode: The iterations count can be defined by the user but always bigger than a minimal value. The password will have minimal requirements that will be dynamically calculated so that the combination (password, iterations count) will always give a security stronger than a predefined minimal limit.
Any thoughts on this?
Thanks.
I think this is a super idea, longer passwords equals shorter mount time..
Jan 8, 2015 at 2:04 PM
idrassi wrote:
One possible solution to this dilemma is to introduce a 2-dimensional criteria for security in VeraCrypt based on the couple (password, iterations count).
I am with the opinion that providing users a choice (provided it doesn't interfere with the main objective of the program, does not overly clutter the UI, shows important warning on value selections etc) is always a good thing.

As you indicated, there are two major types of users: the non tech-savvy (NTS) and the tech-savvy (TS).
The NTS type will use the program as is, with all its defaults. You, the developer, have the responsibility to protect him, withing reason, from a bad choice.
The TS type will tweak the defaults to his liking, but it may still be a good idea to warn on a bad choice. I assume that the TS type fully understands the meaning of a "strong password" and the KDF iterations offered to stretch it.

The idea of auto-correlating PW length to security, and stretch it accordingly, is something that I would be hesitant to endorse for both types of users. It is practically impossible to determine what makes a non-random password secure, and I'd hate to see a minimum iteration count on "JohnnyAppleseed123" as an entered PW by a user named Johnny Appleseed, giving him a false sense of security.

I still stick to my original request - having a user-defined parameter (either in the GUI, with a cautionary note "know what you are doing" for the tweakers, or as a parameter in an ini file), set with a default high iteration value. Johnny Appleseed will not touch it, while Wiley C. Expert will know how to treat it.
Jan 8, 2015 at 2:51 PM
idrassi wrote:
Since its birth, the spirit of VeraCrypt is to provide the maximum possible security.
Please don't start to deviate from this admirable goal quoted above. If you do start to dumb VeraCrypt down you will fade into the background with all the other encryption programs. At the moment VeraCrypt is the leading example in how it should be done.
Since then, I regularly explain why this mounting time is needed to give a standard security level to all VeraCrypt volumes.
As mentioned before, please write one single web-page explaining this in detail. From then on all you have to do is simply provide a link on any forum post written by someone who doesn't understand what the delay is for or why it is so important. It will also allow members like myself to direct people to the same page saving you time.

If a user believes their information is worth encrypting then it may as well be done properly. Allowing users to cripple / weaken volumes is project suicide.

If users want weaker security there are other programs to choose from. If VeraCrypt volumes are broken because the user is allowed to deliberately weaken the authentication, I wish you all the luck in the world trying to reduce the damage that would do to VeraCrypt's reputation. You would never recover from it.

You had a good idea making the hash time proportional to the password length. However the users will let you down. I suspect there will be many padded passwords used to bypass the full authentication hash time. Such as qwerty123 qwertymypass 123456789pass etc.

All I ask is you please retain your original stance, VeraCrypt should lead the way, not pander to the lowest skilled user.

If you really want to stop the complaints about the wait time when booting I suggest you make the 32bit calculation feature ASAP.

Hold firm Mounir, don't loose sight of the real goal for VeraCrypt, others are supporting your original ambition. :)
Jan 8, 2015 at 7:26 PM
Just registered to comment on this....

First of all kudos to all developers working on VeraCrypt, which currently looks like the only open source alternative to crossplatform encryption, CipherShed seems to be lagging a bit behind.

To be on topic: we have a number of machines running Truecrypt (system encryption + volumes on top here and there) and the only blocker to migrate to VeraCrypt is this issue. Migration is not a question, it must be done.
Let's separate system encryption and volumes. When booting you do not have a GUI nor any indicator that you mistyped the password or not and the wait time measured in minutes creates a huge frustration in our users. We went out, collected feedback and this will not fly. These people are technical quys (developers, QA, testers, etc.), so we can enforce a secure password policy (complex 32 character password? okay!), but boot wait times because of encryption cannot exceed ~10 seconds.

When mounting volumes there is a GUI, so ~30 second wait times are tolerable. So the suggested static / dynamic modes would be a much needed feature. A good dynamic mode policy imho would not weaken security and better wait times could be achieved, so we could roll out VeraCrypt to all our machines.

Users should not be underestimated, using Truecrypt / Veracrypt requires an advanced - security aware - user or a good IT staff who deploys the software responsibly. Who is not a knowledgeable user will not alter the defaults. Also this can be and should be well documented. But there should be a choice.

We would gladly go through the source compilation process, however e.g. Windows kernel driver signing is a fun game...

To summarize: please provide this feature or sg. similar to lower mount times! Also maybe system encryption / volume mounts could be handled separately...
Jan 9, 2015 at 12:26 PM
What busy lives other people lead where the secure authentication of VeraCrypt, measured in seconds, is an unbearable time to wait. :)

I find it interesting that all of a sudden we are receiving requests from new members asking us to weaken or cripple VeraCrypt's security. VeraCrypt is certainly worrying some people :)

If your users are not prepared to wait in order to enjoy the security benefits of this feature, it is clear their threat model is not significant enough to use VeraCrypt.

I suggest they seek a weaker and less secure product, there are plenty available.
Jan 9, 2015 at 12:41 PM
We are seeking the best and most secure product without "surprises", namely backdoors. So all closed source, proprietary products are out of the question. The audit of the Truecrypt source gave us confidence to use it for company purposes.

That is why we are seeking a balance between security and usability, because we (as an IT staff) are juggling a whole bunch of users, but I'm sure this is nothing new. Personally I have the patience to wait, but not all of our userbase has that. They do not focus on security, the just "want to get work done". System encryption is (of course) part of our security policy.

Sure, we can wait for Ciphershed to mature and start using it or purchase certificates and modify/compile VeraCrypt sources to have an internal build.
However I think a larger user base benefits all open source projects. I have not done extensive research on the number of complaints, I am only sharing our perspective.

We do not want Veracrypt security to be weakened. As far as my understanding goes a good dynamic policy suggested above would not weaken security.
Long and complex passwords == shorter wait time. Or am I mistaken? Let's assume that we can enforce the complexity of our passwords (so no 'qwerty12345678' strings....).
Jan 9, 2015 at 1:05 PM
Edited Jan 9, 2015 at 1:09 PM
We went out, collected feedback and this will not fly.

I have not done extensive research on the number of complaints
I am not sure of the contradiction.

.
The audit of the Truecrypt source gave us confidence to use it for company purposes.

not all of our userbase has that. They do not focus on security,
TrueCrypt will be secure enough for them, their threat model is clearly not significant enough.

.
We do not want Veracrypt security to be weakened.
Do you believe reducing iterations will strengthen security ? If so you have misunderstood what they are for.

.
Let's assume that we can enforce the complexity of our passwords
You are making a huge mistake here, you cannot assume anything with this type of user. If they cannot be bothered to wait for a volume to mount then they certainly will not bother to type a long password, particularly a random one.

VeraCrypt is 100% about security, your users are is not. TrueCrypt or ChipherShed (when available) will be enough for them.
Jan 9, 2015 at 1:43 PM
L0ck wrote:
We went out, collected feedback and this will not fly.

I have not done extensive research on the number of complaints
I am not sure of the contradiction.
We collected feedback internally, I have not research the Veracrypt user base (forums, mailing lists, Twitter, etc.) extensively.

.
.
The audit of the Truecrypt source gave us confidence to use it for company purposes.

not all of our userbase has that. They do not focus on security,
TrueCrypt will be secure enough for them, their threat model is clearly not significant enough.
The policy dictating the use of encryption is managed by our company IT staff. Our internal users do not care about the product used, it is the responsibility of the IT staff.

.
.
We do not want Veracrypt security to be weakened.
Do you believe reducing iterations will strengthen security ? If so you have misunderstood what they are for.
Iteration count and password length correlates. Just an example: a 64 character password with a low iteration count can be as secure as a 16 character password with a high iteration count. If this is not correct than I am wrong.

.
Let's assume that we can enforce the complexity of our passwords
You are making a huge mistake here, you cannot assume anything with this type of user. If they cannot be bothered to wait for a volume to mount then they certainly will not bother to type a long password, particularly a random one.
Handing out newly installed workstations/notebooks is a managed process. Let me assure you that we can enforce password length and complexity without knowing the user password. We always explain the risks of password length and complexity, this is well understood (as I said we are dealing mostly with developers who know e.g. what a password hash function is). Also length can be easily checked without revealing the current password.

.
VeraCrypt is 100% about security, your users are is not. TrueCrypt or ChipherShed (when available) will be enough for them.
Truecrypt is a dead product, it is not supported, so it's not a viable option.
I do not want to offend the CipherShed community, however based on support, code maturity, number of commits VeraCrypt looks superior compared to CipherShed. Let me state that this is only my personal opinion.

I still hope that for larger deployments where only a group (e.g. a Security department) cares about the product used there can be a compromise. Of course you can turn these users away, however this way you reach only a smaller user base.
Jan 9, 2015 at 2:21 PM
Edited Jan 9, 2015 at 2:22 PM
The policy dictating the use of encryption is managed by our company IT staff. Our internal users do not care about the product used, it is the responsibility of the IT staff.
If you have a policy where the IT staff can decide then enforce VeraCrypt as is. The users are obviously employed staff, surly they have to comply with company policy ? If the IT staff believe the security threat model requires the strength VeraCrypt offers then I don't understand the request to weaken it.

.
Iteration count and password length correlates. Just an example: a 64 character password with a low iteration count can be as secure as a 16 character password with a high iteration count. If this is not correct than I am wrong.
It does, but if your users are complaining at having to wait ~30 seconds (time they could use to do something else), then they are unlikely to remain silent about having to type a 64 character random password.

.
Let me assure you that we can enforce password length and complexity without knowing the user password.
I would love to know how this is done for VeraCrypt boot drives. If it is not a trade secret please explain.

.
Truecrypt is a dead product, it is not supported, so it's not a viable option.
As far as anyone knows the crypto is good. It is weak enough to allow fast password authentication which was the requirement you are requesting.

.
Of course you can turn these users away, however this way you reach only a smaller user base.
Only the user can decide if they want security or speed. VeraCrypt for security, TrueCrypt and [insert weak crypto product here] for speed.

The decision is not ours to make, obviously we believe VeraCrypt is best because it is 100% security minded. Access speed is for less critical data and home users etc.

Don't forget, there will be an update to VeraCrypt in the future to allow 32bit calculations, this will probably halve the boot time. So everyone is happy, faster booting for you, same level of security for everyone else.

If you require this feature sooner and considering you are using VeraCrypt commercially, why not offer to make a contribution to the project and pay Mounir to implement it ? VeraCrypt receives very little financial support.
Coordinator
Jan 9, 2015 at 3:11 PM
Thank you ikkhares for your feedback. It is indeed very important to have other point of view about the usage of VeraCrypt especially in professional environments.

I understand also the point of view of L0ck which I share. But at the same time, I have to think more globally in order to make security more practical and that's why I came up with idea of correlating password length and iteration count in order to always achieve the same secure level. Also one must not forget that if random keyfiles are used, then VeraCrypt will benefit from about 500 bits entropy which make the use a lower iterations count (let's 100 000) more than enough.

VeraCrypt defaults will always remain the same as today. I now believe that adding a dynamic iterations count (fixed by the user with a minimal constraint correlated to the password length) and adding an adequate warning about the risks of using a falsely secure password will make VeraCrypt more versatile but also more secure since a potential attacker will have to guess two variables (iterations/password) instead of only one (password).

This goes against L0ck and ikkhares opinions but the advantages of this ideas surpasses all the risks expressed so far.

Of course, I will start with a preview implementation in order to have early adopters feedback. Nothing is better than confronting an idea to real world use cases. The implementation should take few weeks so nothing will be available before the end of the month.

This discussion is still open.
Jan 9, 2015 at 3:32 PM
Idrassi, can you then make it chooseble between the to "modes", so we are able to keep the current funktion? So we keep it like it is right now, just add a option to turn on the "calc" of iterations..
Jan 9, 2015 at 3:38 PM
L0ck wrote:
If you have a policy where the IT staff can decide then enforce VeraCrypt as is. The users are obviously employed staff, surly they have to comply with company policy? If the IT staff believe the security threat model requires the strength VeraCrypt offers then I don't understand the request to weaken it.

.
Our policies are subject to user feedback. Of course we could try to push the most secure policy ever, however this would alienate people and cause numerous internal conflicts. So sadly even this question is subject to company politics but let's not deviate.

.
Iteration count and password length correlates. Just an example: a 64 character password with a low iteration count can be as secure as a 16 character password with a high iteration count. If this is not correct than I am wrong.
It does, but if your users are complaining at having to wait ~30 seconds (time they could use to do something else), then they are unlikely to remain silent about having to type a 64 character random password.

.
So a secure dynamic policy could be implemented, a compromise could be reached. Lengths were only an example.

.
Let me assure you that we can enforce password length and complexity without knowing the user password.
I would love to know how this is done for VeraCrypt boot drives. If it is not a trade secret please explain.

.
I tried to elaborate, no secrets here, simply we use internal education trainings and length can be easily checked during handover. There is a whole process and training for a new user, encryption is only a piece of the puzzle.

.
Truecrypt is a dead product, it is not supported, so it's not a viable option.
As far as anyone knows the crypto is good. It is weak enough to allow fast password authentication which was the requirement you are requesting.

.
We will not use a product which is no longer fixed, updated and supported.

.
Don't forget, there will be an update to VeraCrypt in the future to allow 32bit calculations, this will probably halve the boot time. So everyone is happy, faster booting for you, same level of security for everyone else.
We are eager to test the new boot loader, however halving boot times will still not be around an acceptable level for our users I guess. We will see.

.
If you require this feature sooner and considering you are using VeraCrypt commercially, why not offer to make a contribution to the project and pay Mounir to implement it ? VeraCrypt receives very little financial support.
We are considering to raise the contribution issue to the management level, we are not dealing with money. Personally I think it would be worth it.

I think I have made our points clear, I cannot add more to this discussion so I will leave this decision up to the developers of VeraCrypt, we can help test this feature if implemented and provide feedback and thanks for everybody who had the time to read all these lengthy comments!
Jan 9, 2015 at 3:53 PM
@idrassi: missed the last comments, the proposed "dynamic iterations count" feature sounds promising! We will be happy to provide feedback.
Jan 9, 2015 at 3:56 PM
Edited Jan 9, 2015 at 3:58 PM
@Mounir

I guess it is not so bad if the default remains, especially if the security aware user is able to dynamically increase the iteration count from the default.

If we can increase iterations from current defaults we don't have to admit VeraCrypt is being weakened, we can claim the dynamic iteration number adds uncertainty to the attacker. :)


Some questions...

What if an inexperienced user forgets how many iterations they defined ? I guess you will need to add an incremental option.

How will VeraCrypt check for poor passwords ? If the user is impatient enough to encourage them to deliberately weaken the iterations then they are unlikely to be patient enough to type a good, strong password.

As we all know, password length does not necessarily equal strength, how will you calculate this ?

I am concerned we will see posts across the Internet saying "My VeraCrypt volume was hacked" without mentioning the modified low iterations used and poor quality password.

Personally I believe the current defaults should be the minimum and allow the user to increase security if they need to. This will confuse the attacker as mentioned before.
Jan 9, 2015 at 3:57 PM
ikkhares wrote:
I tried to elaborate, no secrets here, simply we use internal education trainings and length can be easily checked during handover. There is a whole process and training for a new user, encryption is only a piece of the puzzle.
Thanks for the reply.

Why not educate the user as to why iterations are important ? Password length is no indication of strength, I was wondering how you checked this without knowing the password ?

.
We are eager to test the new boot loader, however halving boot times will still not be around an acceptable level for our users I guess. We will see.
They must be incredibly busy people :)

.
We are considering to raise the contribution issue to the management level, we are not dealing with money. Personally I think it would be worth it.
Yay, any contribution would be welcome. The 32bit calculation would still be useful to you personally, it would mean you could use 2 times the iterations your users would find acceptable currently.
Jan 9, 2015 at 4:45 PM
Hello Mounir,

I echo your statements and proposal for Static Mode (default) and Dynamic Mode as a balance of security and usability.

Forgive my ignorance on the PKF iterations. My questions are can I use Static Mode for certain volumes that are not mounted frequently and Dynamic Mode for volumes that are mounted frequently? Or can I only use one setting for all volumes?

Thank you for being open minded and proposing solutions to satisfy a diverse group of users of VeraCrypt.
Jan 9, 2015 at 5:17 PM
I have just thought of another problem to add to my previous questions above.

How will you ensure that VeraCrypt cannot be manipulated by malware, malicious code etc to enable the crippled feature without the user knowing ?

I am guessing it will be easier to maliciously enable an installed feature, rather than trying to undermine the iteration count on the current version of VeraCrypt.

The more I think about this the more I believe it is the slippery slope. It is akin to asking children what they want to eat for dinner, they will always reply "sweets". Any parent knows they will please their children and be popular by feeding them sweets, but that does not make them a good parent.

A clean break would be preferable, a full version of VeraCrypt and a "lite" weak version. Hopefully this will insulate the full version from any suspicion or false claims of being cracked.
Jan 9, 2015 at 5:35 PM
Edited Jan 9, 2015 at 5:39 PM
idrassi, when you get into the design phase, please consider the people who still use an over-worked 4-years old Celeron - how long will they have to wait to mount a volume? Can't just tell them that they need to suffer for the sake of security, if a high-quality password will provide instantly the same security (*) as a grossly stretched one.

(*) My password policy is to have PW with 128-bit security. Stretching it by a KDF will not add any meaningful security against any adversary. People with lower quality PW will benefit from the stretching, hence my original request to make it user-definable.
Jan 9, 2015 at 5:46 PM
Edited Jan 9, 2015 at 5:59 PM
ninveh wrote:
idrassi, when you get into the design phase, please consider the people who still use an over-worked 4-years old Celeron - how long will they have to wait to mount a volume? Can't just tell them that they need to suffer for the sake of security, if a high-quality password will provide instantly the same security (*) as a grossly stretched one.
.
This is not personally against you ninveh, please don't take it that way.

However your post rather nicely backs up my point I was trying to say to Mounir, only a few posts down from accepting to add an option to weaken the authentication and we already have more requests for crippling.

If you go down this route Mounir you will eventually be persuaded to make VeraCrypt as weak as every other product.

VeraCrypt should be the example all others imitate, it should not partake in a race to the bottom.

Mounir, please think very hard about what you are contemplating doing to VeraCrypt, remember your original goals and please try to stick to them. Going against some users wishes may feel unpleasant, but you are protecting them more and keeping VeraCrypt at the top if you hold firm.

To date, there have been 9828 downloads of the latest release and a handful of complaints about speed.
Jan 9, 2015 at 8:00 PM
This discussion is getting way too heated, which it should not be.

Regarding malware, reputation: you cannot protect against every attack vector out there, the evil maid attack, hardware/software keyloggers are out there.
If the password is stolen through a keylogger and there are no keyfiles, there can be a headline that "VeraCrypt was hacked".

I just comment to highlight one thing: there is a distinction between system encryption and volume mounting from an end user perspective. To use it in an enterprise environment a ~10 second wait time is tolerated for system encryption by the end users (on modern systems). If that cannot be achieved than another product must be evaluated, VeraCrypt security level will remain very high, but the user base will be smaller and enterprise users will be excluded.

However attaining a big user base including enterprise users should be a healthy project goal.

It seems that there will be a proposed solution to favor both sides, let's just wait for it and test it thoroughly and thank the developers for keeping an open mind!
Jan 9, 2015 at 8:31 PM
Edited Jan 9, 2015 at 8:32 PM
This discussion is getting way too heated, which it should not be.
I haven't seen anyone's posts being "way too heated", who are you accusing ?

.
you cannot protect against every attack vector out there, the evil maid attack
True but it does not mean we should simply give up, also the evil maid attack may possibly be addressed in a future release.

.
However attaining a big user base including enterprise users should be a healthy project goal.
At what cost ? Being popular doesn't mean better, Windows is popular, does that mean you believe it to be more secure than Linux ?

Don't forget you are all forcing Mounir to go against his personal principles regarding VeraCrypt. I don't think any of you should be proud of this thread.
Jan 9, 2015 at 8:44 PM
Don't get me wrong, I am not accusing nor am I forcing anybody. I am just stating facts from the enterprise perspective to highlight the distinction between "home security enthusiast" versus "enterprise end user who is forced to follow a dumb IT policy (in their opinion)". I am not saying that X product is better than Y, I am just stating that for VeraCrypt to be accepted by enterprise users this problem must be tackled somehow.

I am sure however that the developers will not implement anything that will harm the overall security of their product. Personally I would not want that.
Jan 9, 2015 at 9:06 PM
Edited Jan 9, 2015 at 9:26 PM
Don't get me wrong, I am not accusing

This discussion is getting way too heated
I just could not find anything on this thread for you to say this, which is why I asked who you were accusing so I could narrow down the search. I wonder if you notice the occasional smiley face I have been writing throughout my posts on this forum. I hope you were not feeling intimidated by my questions / replies.

.
enterprise end user who is forced to follow a dumb IT policy (in their opinion)".
I totally agree with you, which is why you should educate them :) You are the IT expert in your business, teach them.

.
I am just stating that for VeraCrypt to be accepted by enterprise users this problem must be tackled somehow.
How is the security of VeraCrypt improved by having enterprise users ?

Also you describe the brute force protection as "this problem", I am not sure exactly what "problem" there is with it. I think you probably would agree with me that the "problem" is impatient non security minded users. Do you think it is a good idea to respect such peoples opinion regarding the future direction an encryption product should take ?

.
I am sure however that the developers will not implement anything that will harm the overall security of their product. Personally I would not want that.
I suspect this is actually happening. Mounir seems to be the sort of person who will try to please people, despite his original goals for VeraCrypt. I think he is just too polite to say, I am however different, as you can see :) LOL

What did you think to my other suggestion ? Quoted below...
A clean break would be preferable, a full version of VeraCrypt and a "lite" weak version. Hopefully this will insulate the full version from any suspicion or false claims of being cracked.
Would your company sponsor a separate lite / less secure version of VeraCrypt ?
Jan 9, 2015 at 9:23 PM
If you have done this you must know that educating a few hundred or thousand people is not that simple. Also from high company rankings your secure policies can be torpedoed in a heartbeat and then you are suddenly on a lower overall security level. ("Encryption is so slow? This is counterproductive, this interferes with business needs, throw it out!).

VeraCrypt in not only about security, it is a software product and as such it has bugs and defects. A large install base, a variety of configurations can reveal these quicker and also provide meaningful feedback. Of course VeraCrypt decides which types of users it wants to focus on.

And lastly the problem is the slowness, not the brute force protection. Latter is a must, former should be eliminated, if it is possible without compromising security.
Jan 9, 2015 at 9:35 PM
Edited Jan 9, 2015 at 9:36 PM
If you have done this you must know that educating a few hundred or thousand people is not that simple.
Write one excellent tutorial, with pictures, press send to all. If they are not competent to follow it, then I would question how they got past the interview stage. I noticed users helped each other once a group of them understood.

.
VeraCrypt in not only about security,
It used to be :(

.
it is a software product and as such it has bugs and defects. A large install base, a variety of configurations can reveal these quicker and also provide meaningful feedback.
There is quite a large group of people downloading every new release of VeraCrypt.

.
And lastly the problem is the slowness, not the brute force protection.
The "slowness" IS the brute force protection, that's how it works. :)

What did you think to my other suggestion ? Quoted below...
A clean break would be preferable, a full version of VeraCrypt and a "lite" weak version. Hopefully this will insulate the full version from any suspicion or false claims of being cracked.
Would your company sponsor a separate lite / less secure version of VeraCrypt ?
Jan 9, 2015 at 9:49 PM
With static iteration count even with a good password (complex, long, etc.) you are subjected to wait needlesly. I think we can agree on that.

I cannot comment on company decisions, personally I think that from a developer perspective it is much harder to support two products then one, also I do not think that this issue validates such a drastic measure.
Jan 9, 2015 at 10:03 PM
Edited Jan 9, 2015 at 10:05 PM
With static iteration count even with a good password (complex, long, etc.) you are subjected to wait needlesly. I think we can agree on that
.
With respect, this is where we don't agree :) It is not fair to call the authentication routine, with it's current brute force protection "needless". Are you aware of how many passwords a humble home user can test, per second, with an inexpensive GPU ?

I know people with 20x brand new top of the range graphics cards built into racks, once you witness it's power you won't feel safe with the current iteration settings in VeraCrypt, never mind when they are reduced.
.
I cannot comment on company decisions, personally I think that from a developer perspective it is much harder to support two products then one, also I do not think that this issue validates such a drastic measure.
Yes supporting two version will be harder, but if you sponsored one to make it worth while and also contribute something to the full VeraCrypt then I can see a reason to need enterprise users.

Separating the two removes any doubt amongst our more paranoid users and believe it or not, I am not the most paranoid here LOL.
Jan 9, 2015 at 11:16 PM
So to summarize your reasoning:
  • User stupidity: We should protect users who use weak passwords with a strong static brute force protection. Okay, however am I able to use a 1 character password now? Yes I am.
  • Reputation: VeraCrypt will be easily hacked without a static brute force protection and this will be all over the news. Okay, but what if I am said stupid user with a 1 character password who "gets hacked" and then VeraCrypt is all over the news. Is this VeraCrypt's fault?
  • Malware modifying VeraCrypt settings: why would someone design malware for this purpose instead of using a dead simple keylogger which is available in the dozens?
With said dynamic policy professionals, who know what they are doing could customize VeraCrypt to suit the environment. Paranoid users could ramp up the iteration count even more or it could be lowered provided a strong and complex password is used. The main point here is the possibility of choice.
Jan 9, 2015 at 11:41 PM
User stupidity: We should protect users who use weak passwords with a strong static brute force protection. Okay,
Good we agree on something. However it is not as simple as that. It is not just to protect user stupidity, it is to provide the strongest resistance to brute force attacks for those who make the effort to use a long password.

.
however am I able to use a 1 character password now? Yes I am.
That's correct.

.
what if I am said stupid user with a 1 character password who "gets hacked" and then VeraCrypt is all over the news. Is this VeraCrypt's fault?
In a way yes it is, I have never argued to allow short passwords, I doubt you could find a quote on this forum where I have. This is a bit of a straw man argument as it does not relate to anything I have said.

.
Malware modifying VeraCrypt settings: why would someone design malware for this purpose instead of using a dead simple keylogger which is available in the dozens?
Antivirus is more likely to pick up a key-logger. Also where would it write the password if it is WDE ? This leaves only physical devices.
Coordinator
Jan 10, 2015 at 9:55 AM
OTP is for authentication and it can't be used for disk encryption. This has been discussed on several places, here is an example of answer concerning this: http://security.stackexchange.com/a/13970
Jan 10, 2015 at 12:04 PM
Edited Jan 10, 2015 at 12:06 PM
ikkhares wrote:
The main point here is the possibility of choice.
I have just realised you probably didn't see my post much further up.

I am all for user choice but there must be basic minimums.

Here's what I said above...
"I guess it is not so bad if the default remains, especially if the security aware user is able to dynamically increase the iteration count from the default.

If we can increase iterations from current defaults we don't have to admit VeraCrypt is being weakened, we can claim the dynamic iteration number adds uncertainty to the attacker. :)"
.
... Again what I wrote further down...

.
"Personally I believe the current defaults should be the minimum and allow the user to increase security if they need to. This will confuse the attacker as mentioned before."
I like the fact the attacker has no idea of what hash type, iteration count or cipher type has been used when presented with a VeraCrypt volume.

What I don't like is this is the first time VeraCrypt will be adding a feature which could potentially weaken it's security, which is a worrying road to start down.

As I demonstrated above in another post, other users immediately requested consideration for old, less powerful systems. This is a slippery slope, once you start to yield to the lowest denominator.

I also asked about just how the "longer" password would be tested. Here is what I said.....
How will VeraCrypt check for poor passwords ? If the user is impatient enough to encourage them to deliberately weaken the iterations then they are unlikely to be patient enough to type a good, strong password.

As we all know, password length does not necessarily equal strength, how will you calculate this ?

I am concerned we will see posts across the Internet saying "My VeraCrypt volume was hacked" without mentioning the modified low iterations used and poor quality password.
This needs to be addressed before any weakening of the iterations is possible in VeraCrypt.

So I am all for user choice, so much in fact I wanted hash cascading to be considered. However I do not believe those without a real need for security should have much say in any feature in VeraCrypt.
Jan 11, 2015 at 11:56 AM
mtpagkatipunan wrote:
How about some sort of a '"slider" selection? Sliding to the left might enforce longer password length but with lower iteration count. While sliding to the right will allow for shorter password length (while enforcing minimum length to ensure considerable security), but with higher iteration count.

This slider will also show the user the relationship of password length and iteration count in his selection. Just like in photography, you select a wider aperture, the camera will adjust the shutter speed, you select a higher shutter speed, the camera will adjust the camera to a more narrow aperture.
It is not a good idea to reduce iterations, you are weakening your protection.

Password length is not always the answer. Password quality can help, unfortunately testing for password quality is going to be a nightmare for Mounir. I worry he will struggle to make a smart enough filter to check. If this filter is not good enough, then we are in the depressing situation where for the first time since conception, VeraCrypt is allowing users to reduce security.

I have proved on this thread and others throughout the forum that the wrong people are being allowed to make requests, with respect to security. Popularity is no guarantee of security, or even good ideas. Most have little comprehension of the real world threat model. Many have no need for the sort of protection offered by VeraCrypt yet refuse to employ a more suitable application. Instead these same people believe it fair to attempt to drag VeraCrypt down to the level of other products, rather than allow it to be a glowing example as to how all encryption products should be.

Not many people will be able to memorise a long, truly random password, sufficient enough to compensate for the reduced iteration count.
Jan 11, 2015 at 1:57 PM
Well, we have the typical security vs usability argument and for the first time I'm on the usability side it seems. I have written security policies always with the most secure alternative in mind, however these always had to be altered to suit the real world needs. If I could I would require a breath test, a drop of blood and penis size for every authentication. (Yes, I hid a joke there, guess which element it is).

If this is the first time this type of argument has come up, than VeraCrypt is gaining popularity. It all really comes down to trusting your user base. As I stated earlier I can supply a 1 character password. I am warned but I am not stopped. It is my responsibility as a user.

And if VeraCrypt continues on becoming popular, which I really hope, then there will be much more debates like this to come...
Jan 11, 2015 at 2:31 PM
ikkhares

I don't think your users requests are for usability, they seem to only be for speed or I would call it weakening. VeraCrypt will not be easier to use.

The ability to use a short password in the current build is actually a security gain, I understand that may seem odd, but with a high iteration count an attacker has to brute force or use password lists from length 1 to whatever while also tackling the high iteration. This is actually a significant workload, if this new crippling feature enforces a minimum password length of say 32 characters then an attackers knows the password cannot be < 32. So word lists and common padding will be used to attack the hash also at a considerably faster rate due to low iterations.

It might not seem credible but longer passwords, certainly those made by people who think a reduced iteration count is a good idea, will no doubt be very predictable.

I do not believe your users will be able to remember a totally random 32 character password, without writing it down or cheating in a predictable way.

I get the sense that you personally understand this is a bad feature to implement, but you are representing your users.

If you truly understand security and the risks this request brings, I am saddened you wish to inflict it on an otherwise purist application, to simply make your life easier at work.

Why not persuade your users to use a faster application ? Security is clearly not a premium to these people so why be concerned about open source etc ? You could always use TrueCrypt until ChiperShed is built and there is always Bitlocker :)

I was just about to post a new thread to solve this. I am going to suggest the crippled version "VeraCrypt Lite" is kept separate.
Jan 11, 2015 at 2:31 PM
Edited Jan 11, 2015 at 2:36 PM
I really don't like if VC becomes "less secure". I think VC should be the most secure crypto program. First I liked the thought about be able to lower the "delay" but the Security should NOT be suffered in order to lower the delay.

Idrassi, please don't lower Security of VC, I think VC should be THE program to use, if the user want the most secure program out there. (Like me)
Jan 11, 2015 at 2:38 PM
destrukt wrote:
I really don't like if VC becomes "less secure". I think VC should be the most secure crypto program. First I liked the thourght about be able to lower the "delay" but the Security should NOT be suffered in order to lower the delay.

Idrassi, please don't lower Security of VC, I think VC should be THE program to use, if the user want the most secure program out there. (Like me)
Yay !! :D

I believe VeraCrypt is "special" and should remain geeky, for those with real security needs. There are many other products much more suitable for those who require little to no security.

Thank you destrukt, you are a honorary crypto geek :) That makes two of us LOL
Jan 11, 2015 at 2:47 PM
**L0ck wrote:
Yay !! :D

I believe VeraCrypt is "special" and should remain geeky, for those with real security needs. There are many other products much more suitable for those who require little to no security.

Thank you destrukt, you are a honorary crypto geek :) That makes two of us LOL
:D!? Yes, we really need VC to be the "leading" and the most secure program "out there". Don't let the Security suffer! :) Keep VC on "track" Idrassi :)
Jan 11, 2015 at 3:01 PM
destrukt wrote:
:D!? Yes, we really need VC to be the "leading" and the most secure program "out there". Don't let the Security suffer! :) Keep VC on "track" Idrassi :)
I believe this was Mounir's original intention, however due to the requests he appears to feel obliged to provide this feature in order to keep some users happy.

I am 100% certain he would not have even contemplated this had he not been nagged.

An important thing to think about...

Mounir, think of all the hours / days / weeks possibly months you have worked on the VeraCrypt code to provide the best security you can. Then consider the fact some users will not even spend ~30 seconds of their time to enjoy the protection you have provided.

I find it insulting and disrespectful to your efforts so far to be honest.
Jan 11, 2015 at 3:03 PM
L0ck wrote:
ikkhares

The ability to use a short password in the current build is actually a security gain, I understand that may seem odd, but with a high iteration count an attacker has to brute force or use password lists from length 1 to whatever while also tackling the high iteration.
Your argument is right, however how would an attacker know which mode was in use? The choice between the two modes and the varied iteration count provides better security, rather then worse if used properly.
.
If you truly understand security and the risks this request brings, I am saddened you wish to inflict it on an otherwise purist application, to simply make your life easier at work.

Why not persuade your users to use a faster application ? Security is clearly not a premium to these people so why be concerned about open source etc ? You could always use TrueCrypt until ChiperShed is built and there is always Bitlocker :)
You are right, I am representing our users, as I wrote in my first post, however I am making my work harder, not easier. We are eligible to use two major commercial encryption products (intentionally not writing names), we have valid licences, however I would trust an open source solution.
.
I do not believe your users will be able to remember a totally random 32 character password

You do not trust them to. I do.
I really cannot understand why an optional feature, which is not mandatory in any way and could even improve security is viewed so catastrophically.
You have to trust the users to use it responsibly.
Jan 11, 2015 at 3:09 PM
I am going to try to summarize the various proposals since this thread has become so long and people viewing this 40+ long posts thread may not know what has been proposed and are just seeing words like "less secure".

RECAP

To reduce the wait times when mounting VeraCrypt volumes at the expense of security of hash brute force attacks. We have a diverse group of people wanting to use VeraCrypt that do not require trying to thwart governments or secret agencies.


SUMMARY PROPOSALS

Static Mode (Default) and Dynamic Mode

Mounir, the developer of VeraCrypt, came up with the following:
.
Today, VeraCrypt security in based on the 1-dimension provided by the password since a static iterations count is used. The password being freely chosen from the user with no limitations, the static count was chosen to offer a fair security for normal passwords.

An evolution can be the activation of a second security dimension by allowing the iterations count to be dynamic but at the same time disallowing it to be below a certain minimal value. In this case, we will add a limitation to the chosen password in order to ensure that it can't be shorter that a certain limit and this limit will be calculate dynamically from the iterations count.

Following this, we can have two security modes:
1.Static Mode: this is the current mode. A fixed high iterations value is used. The password can have any length.
2.Dynamic Mode: The iterations count can be defined by the user but always bigger than a minimal value. The password will have minimal requirements that will be dynamically calculated so that the combination (password, iterations count) will always give a security stronger than a predefined minimal limit.
.
The only addition I would make to Mounir's suggestion is that a warning box be provided when selecting the Dynamic Mode regarding hash brute force hacking or something along the lines of less secure with an brief explanation of why it is less secure. Let the user decide what is their threat model.

User Configurable Iteration Count

Another suggestion was to allow the iteration to be user defined from the default presets to suit the user's balance of security and usability for the wait times of mounting the volume(s).

Slider Selection

mtpagkatipunan wrote:
How about some sort of a '"slider" selection? Sliding to the left might enforce longer password length but with lower iteration count. While sliding to the right will allow for shorter password length (while enforcing minimum length to ensure considerable security), but with higher iteration count.

This slider will also show the user the relationship of password length and iteration count in his selection. Just like in photography, you select a wider aperture, the camera will adjust the shutter speed, you select a higher shutter speed, the camera will adjust the camera to a more narrow aperture.

Of course, one can have the option to put both settings in extremes (longer password, higher iteration), but certainly will not allow setting both to lower extremes).
.

VeraCrypt Lite

Have two different branches of the code. The current code will continue to use the non-configurable high iteration counts for the hashes and the lite version will allow for user configurable iterations for the hashes.
Jan 11, 2015 at 3:23 PM
Your argument is right, however how would an attacker know which mode was in use?
Your company policy to use it will leak out, especially with so many users.

.
You are right, I am representing our users,
You are representing a small number of people who are not security aware, have little need for the full protection of VeraCrypt and presumably will complain about length 32 random passwords.

.
We are eligible to use two major commercial encryption products (intentionally not writing names), we have valid licences, however I would trust an open source solution.
It would be more fair to VeraCrypt "genuine" users if you employed one of the commercial programs you already have a licence for.

You have no need for open source as your security requirements are so low. You are doing the equivalent of driving a Ferrari to go shopping.

TrueCrypt is open source and has been audited, it is more than fast enough for your users. CipherShed will hopefully be available soon and they will probably bend to demands like this more readily. VeraCrypt was the holy grail, the standard to imitate and judge others on, if you are a true crypto geek at heart then please don't try to drag us down.

.
You have to trust the users to use it responsibly.
It is good secure practice to always assume there is an idiot at the keyboard.
Jan 11, 2015 at 3:31 PM
Edited Jan 11, 2015 at 3:38 PM
Enigma2Illusion wrote:
I am going to try to summarize the various proposals since this thread has become so long and people viewing this 40+ long posts thread may not know what has been proposed and are just seeing words like "less secure".
.

You have failed to make an unbiased selection in your post, attempting to represent the thread in some sort of official manner, which you are not. You are no more a significant member here than anyone else.

.
are just seeing words like "less secure".
.
So they should, only a few of us understand this topic and need to make a lot of noise about it. If you respect Mounir as much as you claim then you should accept his personal opinion on this matter. Without all the nagging there is no way he would have contemplated doing this to VeraCrypt.

.
We have a diverse group of people wanting to use VeraCrypt that do not require trying to thwart governments or secret agencies.
.

The line above almost appears to be conceding that this is a less secure option after all :)
Jan 11, 2015 at 3:36 PM
L0ck wrote:
So I am all for user choice, so much in fact I wanted hash cascading to be considered. However I do not believe those without a real need for security should have much say in any feature in VeraCrypt.
.
That last sentence you wrote L0ck is troubling me. Maybe I am misinterpreting your message.

None of us are here to decide that other people's feature requests or suggestions are considered "real" security and therefore if they should have any say in any feature in VeraCrypt. We have a diverse group of people wanting to use VeraCrypt. Debating an idea is fine up to a point. :)

Both you and ikkhares have clearly articulated your positions. Mounir has made his decision to proceed with a beta in the future months with Static Mode (default) and Dynamic Mode with a warning message as outlined in this thread.

Let's not turn this into a personal vendetta against other forum members you disagree with or say their needs are not "real" security or that they should have little say in any feature in VeraCrypt.

The VeraCrypt project will benefit from having a diverse user base feeling comfortable making feature requests and suggestions for their needs which may be debated to determine the best course of action or if the idea should be rejected. Mounir will let us know his decision to accept or reject the ideas being presented.
Jan 11, 2015 at 3:51 PM
I notice you side stepped all my more "difficult" points throughout this thread. I assume you conceded.

As mentioned many times on this thread and throughout the forum, VeraCrypt's whole conception was to be the best security available, no compromise.

Others who have no need for a no compromise solution have plenty of other products to chose from, those with real security interests have no other option.

Trying to play at moderator does not work with me, I know your limitations.

I am debating with others on this thread in an effort to defend VeraCrypt, you are welcome to join in with something constructive.

.
We have a diverse group of people wanting to use VeraCrypt that do not require trying to thwart governments or secret agencies.
.

So are you saying this does weaken security or not ?
Jan 11, 2015 at 4:07 PM
L0ck, you are clearly letting your emotions cloud your judgment.

You have summarized proposals in other long running threads that I participated in debating. Why is my summary considered "playing moderator" and not your summaries?

I tried my best to summarize the various proposals and my genuine concern was people not following this thread in detail from start to finish and were just skimming to get the jest therefore seeing "less secure" out of context.

The reason I am not going to debate you is because your posts say to me that you will not accept compromise solutions. I believe the proposal from Mounir preserves the high security that you seek as it will be the default setting and the dynamic mode option for the user base that needs faster mount times.
Jan 11, 2015 at 4:26 PM
L0ck, you are clearly letting your emotions cloud your judgment.
.

You are attempting a distraction argument, but failed. This indicates you are defensive and not arguing the case but attempting to recover some dignity, which has again failed. It is also very patronising, a very poor comeback.

.
You have summarized proposals in other long running threads that I participated in debating. Why is my summary considered "playing moderator" and not your summaries?
When I do it I am speaking for myself to the person I am debating, I don't claim or try to give the impression I am doing for the rest of the forum. In light of that I can make my posts how I like, you made an extremely biased post without any acknowledgement of my security points. If I see a valid counter point I would, however reluctantly, include it.

.
I tried my best to summarize the various proposals and my genuine concern was people not following this thread in detail from start to finish and were just skimming to get the jest therefore seeing "less secure" out of context.
Less secure didn't get a mention in your "summary" other than to attempt to play it down.

If someone wishes to have a vote on the future of VeraCrypt is it really too much to ask they read a thread ?

.
The reason I am not going to debate you is because your posts say to me that you will not accept compromise solutions.
No compromise to security was the goal of VeraCrypt. I am simply trying to retain that noble aim.

This is an honest and genuine question for you.

Do you honestly believe Mounir would have even contemplated this feature had it not been for the nagging by inpatient users ?

This is not a security enhancement but an effort to silence the people desiring speed over security.
Jan 11, 2015 at 4:40 PM
After Reading this compleate thread(again), I am only left with one question...

Why use a "secure" product, if you don't need the Security?

The users who is asking for "speed over security" why not just use TC, Bitlocker or wait for ChiperShed?

I can't see why Idrassi should make af ChiperShed clone (VC Lite)? Use the time on the most important thing, keep VC at the edge of crypto software...

Peace out :D
Jan 11, 2015 at 4:46 PM
destrukt wrote:
After Reading this compleate thread(again), I am only left with one question...

Why use a "secure" product, if you don't need the Security?

The users who is asking for "speed over security" why not just use TC, Bitlocker or wait for ChiperShed?

I can't see why Idrassi should make af ChiperShed clone (VC Lite)? Use the time on the most important thing, keep VC at the edge of crypto software...

Peace out :D
Thank you, someone who is security aware :)

Please take a look at my other suggestion, if you agree with it then please comment.

https://veracrypt.codeplex.com/discussions/577405#editor


Also I will make this point again.

I am all for user defined iterations as this adds uncertainty to the attacker, but NOT for the ability to REDUCE them from the current default. VeraCrypt must remain 100% about security.
Jan 11, 2015 at 5:17 PM
L0ck,

I will remind you that Mounir openly stated that he wanted VeraCrypt to be widely used by both non-technical and technical users and to have wide user base.

There are many features that Mounir never considered until the user community began making request in the Issues section and/or from the user forums on CodePlex and SourceForge.

At this point we cannot have a civil discussion and I am not going to continue to reply to your acidic responses. If you feel vindicated by my lack of future responses to you in this thread, fine.

One suggestion I have for everyone, we have beat this topic to death. There were questions of how Mounir would implement the Dynamic Mode password strength / iteration count. Perhaps the community can assist Mounir by providing him with ideas. Lets not be too harsh on the bad on ideas. :) Think of it as a brainstorming session.

This is beyond my skillset so at the moment I do not have any ideas to offer regarding the password strength / iteration count procedure. If I come across something in the future on the internet, I will post it to this thread.

Kind Regards,
Enigma2Illusion
Jan 11, 2015 at 5:30 PM
There are many features that Mounir never considered until the user community began making request in the Issues section and/or from the user forums on CodePlex and SourceForge.
.

None of which were to reduce security.

.
If you feel vindicated by my lack of future responses to you in this thread, fine.
.

I do. Evidence is there for all to see.

.
There were questions of how Mounir would implement the Dynamic Mode password strength / iteration count.
.

This is the weak part of the request, I am keen to see the finished version, assessing password strength is incredibly hard. I look forward to testing it.

.
This is beyond my skillset so at the moment I do not have any ideas to offer regarding the password strength / iteration count procedure.
.

I could make a joke here but I managed to restrain myself, those in the know get it LOL
Jan 11, 2015 at 6:34 PM
For teh love of god there are enough cr@p crypto apps out there, leave veracrypt as it is.

yeah i have read the thread veracrypt needs to stay strong, reducing is not teh way to go dude.
Jan 11, 2015 at 7:52 PM
Edited Jan 11, 2015 at 8:09 PM
Cipher1 wrote:
For teh love of god there are enough cr@p crypto apps out there, leave veracrypt as it is.

yeah i have read the thread veracrypt needs to stay strong, reducing is not teh way to go dude.
Thank you, I agree also, any reduction is a step in the wrong direction and sends a bad signal that VeraCrypt will change principles due to pressure from a few.

As you say, there are already other less secure products available, I have suggested many times that these 3 members use those instead.

I have even suggested VeraCrypt Lite as a compromise, however Enigma2Illusion, ikkhares and ninveh seem to want this to have a detrimental affect on the full version of VeraCrypt directly, seemingly rejecting offers of a Lite version.

I have to say, I am starting to become suspicious of their motives for this request. Other options have been provided and good reasons have been explained as to why this is not a good idea from a security perspective. However they appear determined to push for a reduction in security in the full version on VeraCrypt.

I notice this came about around the time we were criticized by the CipherShed team, I do hope this is not an attempt to drag VeraCrypt down. The default, high iteration count was a stick I was able to beat CipherShed with on our forum, shortly after this encounter we get this tag team effort to reduce it.

Let me be VERY clear, optional iterations are a good thing as long as the minimum default is retained as it is now. This is VeraCrypt's strong point, no compromise on security.

I have not read anything from these 3 as to how reducing iterations, regardless of their faith in longer passwords which should be used anyway, adds security to VeraCrypt. I fully understand and agree with user defined iteration numbers but not to reduce !

I believe I have done enough to demonstrate users who are not prepared to wait to open a volume, or boot a drive, are not security aware or in need of the security offered by VeraCrypt.

This is a long thread and we have yet to see a valid pro security reason to reduce iterations, unless you consider impatience a security issue.

EDIT

Actually thinking about this more, there is even less need to reduce as once the 32bit calculations are enabled the boot time will probably halve. If half the delay is not acceptable then you really have no grounds for an argument.
Jan 11, 2015 at 8:16 PM
Dear all,

Just a hopefully civilized response regarding this matter: it clearly seems that there is a group of people who have a very strong opinion and defend it viciously and are even suggesting ill will from those (new?) users who formed a different opinion.

As I have registered a few days ago I have not dived into all the forums, posts, I do not know what intentions and strategy the developers of VeraCrypt have, what user base they targeted, etc. Or maybe there is only 1 VeraCrypt developer, I don't know, I am speaking from my personal experience regarding user base, ecetera.

There are really a lot of posts now and before this escalates even further I really think that we have to lay back a few days and let @idrassi let us know what he will do, what direction he wants to go. Both sides stated their arguments in lengths.

I do not wish to harm this project, quite the contrary, however I would be glad if I could be treated like a welcomed new forum member.

As we have seen all points and counterpoints I do not wish to debate this any further.
Jan 11, 2015 at 8:19 PM
Hi!

KeePass Password Safe has an option to choose the number of key transformation rounds to use. Does this app is unsecure because of this? Nope. IMHO, VeraCrypt should have it too. If you are so paranoid, just make it as a hidden option, so a newbie user won't find it.

VC is great, but it can be even better. There are folks who use slower PCs, please don't rule them out. Thanks.
Jan 11, 2015 at 9:25 PM
Edited Jan 11, 2015 at 9:26 PM
I would like to propose an approach that may satisfy everyone!!

1) Strengthen security via my proposed "UniCode 8.0 basis for VeraCrypt" issue as described here: https://veracrypt.codeplex.com/workitem/62
2) Calculate the reduced iteration count that would result in the same level of security as before
3) Determine the amount of time taken during bootup that is acceptable to enterprise users like ikkhares
4) If (as I suspect) the reduced iteration count can be performed on ordinary hardware in less time than enterprise users allow, then increase the iteration count accordingly to effectively use all of that time to deter attackers.

By applying the security improvement I propose, we can "pay for" the shorter boot time without reducing security (and increase security as well)!!

I welcome everyone's thoughts on this approach. If you like it, please upvote the UniCode 8.0 issue here: https://veracrypt.codeplex.com/workitem/62
Jan 11, 2015 at 9:42 PM
This is the most constructive comment I have read so far, thumbs up for that. Boot time is the most crucial in our case and the question is that can Unicode support be incorporated into the boot loader code with it's restrictions? If this is feasible then this could be the best solution!
Jan 11, 2015 at 9:45 PM
ikkhares wrote:
it clearly seems that there is a group of people who have a very strong opinion and defend it viciously
.
I don't mind you backing down and exiting the debate, but please don't pretend you have been treated viciously, if you truly believe that you are way too sensitive to join internet forums. You implied you were working so I assumed you were of adult age.

.
As I have registered a few days ago I have not dived into all the forums, posts, I do not know what intentions and strategy the developers of VeraCrypt have, what user base they targeted, etc.
.
This was very clear by your requests, VeraCrypt is / was very special to its members. Any attempt to weaken it, however innocently claimed, will not be accepted lightly.

.
I do not wish to harm this project, quite the contrary,
.
If the quote above is true, then re-read this thread and accept one of the many other options provided for you. However if you have managed to come up with a valid pro security reason to reduce iterations, I would love to hear from you, or a representative posting for you.

.
As we have seen all points and counterpoints I do not wish to debate this any further.
.
Accepted.
Jan 11, 2015 at 9:45 PM
Mrere wrote:
KeePass Password Safe has an option to choose the number of key transformation rounds to use. Does this app is unsecure because of this? Nope.
.
Many times I have explained on this thread that having the option for the user to increase iterations from the current default is a good thing. The problem is when you intentionally REDUCE the number.

The excuse of upping the password length is ridiculous as a long password should be employed anyway.

.
There are folks who use slower PCs, please don't rule them out
.
They are not ruled out, where does it say that, please provide a quote.

If users require real security they have to understand security costs. In this case the charge is a 30 second delay before booting. If 30 seconds is too expensive for the level of security you require then VeraCrypt is not the application for you. It's not like there aren't other tools for you to use, why drag us down ?
Jan 11, 2015 at 9:48 PM
commenter8 wrote:
I would like to propose an approach that may satisfy everyone!!
Hi commenter8 :)

Good idea but users should be using long passwords anyway.

Longer passwords, the current high iteration count and your UniCode idea would be very strong.

No need or excuse to reduce security elsewhere though.
Jan 11, 2015 at 9:49 PM
Edited Jan 11, 2015 at 9:59 PM
ikkhares wrote:
Boot time is the most crucial in our case
Boot time will be almost halved soon anyway.
Jan 11, 2015 at 10:04 PM
ikkhares wrote:
This is the most constructive comment I have read so far, thumbs up for that. Boot time is the most crucial in our case and the question is that can Unicode support be incorporated into the boot loader code with it's restrictions? If this is feasible then this could be the best solution!
Can you provide some insight into point 3) by indicating the highest amount of VeraCrypt time during bootup that you would be able to accept? Thanks!
Jan 11, 2015 at 10:10 PM
Edited Jan 11, 2015 at 10:11 PM
commenter8 wrote:
ikkhares wrote:
This is the most constructive comment I have read so far, thumbs up for that. Boot time is the most crucial in our case and the question is that can Unicode support be incorporated into the boot loader code with it's restrictions? If this is feasible then this could be the best solution!
Can you provide some insight into point 3) by indicating the highest amount of VeraCrypt time during bootup that you would be able to accept? Thanks!
.

They basically demand instant ...

ikkhares
We are eager to test the new boot loader, however halving boot times will still not be around an acceptable level for our users
Jan 11, 2015 at 10:15 PM
L0ck wrote:
commenter8 wrote:
ikkhares wrote:
This is the most constructive comment I have read so far, thumbs up for that. Boot time is the most crucial in our case and the question is that can Unicode support be incorporated into the boot loader code with it's restrictions? If this is feasible then this could be the best solution!
Can you provide some insight into point 3) by indicating the highest amount of VeraCrypt time during bootup that you would be able to accept? Thanks!
.

They basically demand instant ...

ikkhares
We are eager to test the new boot loader, however halving boot times will still not be around an acceptable level for our users
Interesting, I thought I wrote the following:

ikkhares wrote:
Just registered to comment on this....

... boot wait times because of encryption cannot exceed ~10 seconds.

When mounting volumes there is a GUI, so ~30 second wait times are tolerable.
Jan 11, 2015 at 10:17 PM
Edited Jan 11, 2015 at 10:23 PM
ikkhares wrote:
Interesting, I thought I wrote the following:
.
You also wrote this LOL

ikkhares wrote:
I do not wish to debate this any further.
.

~10 seconds in crypto terms is almost instant, my comment stands.
Jan 11, 2015 at 10:24 PM
Yes I did. I do not see myself debating, also as I wrote I wish to be treated fairly, just as I treat others in this thread, regardless of their stance.
Jan 11, 2015 at 10:25 PM
ikkhares wrote:
Yes I did. I do not see myself debating, also as I wrote I wish to be treated fairly, just as I treat others in this thread, regardless of their stance.
.

How have you been treated unfairly ?
Jan 11, 2015 at 10:27 PM
Please excuse me for that, but I do not wish to bring this discussion to a personal level.
Jan 11, 2015 at 10:35 PM
Thank you ikkhares, that is very helpful.

It seems to me that the time needed during bootup consists of two factors:

a) Time needed to process the passphrase
b) Time needed to fully decrypt the boot volume

I further conjecture that b) will be directly proportional to the size (in gigabytes) of the boot volume.

It may therefore be possible to specify a maximum size for the boot volume that VeraCrypt can support.

According to this page 64-bit Windows 8 needs 20 GB: http://windows.microsoft.com/en-us/windows-8/system-requirements

Since Windows appears to demand far more space than Linux or Mac OS, it seems that we can take its needs as the maximum.

Room for a paging file, etc. is also needed; according to this page 4 GB is the maximum paging file size: http://support.microsoft.com/kb/2860880

So a generous allowance for an operating system volume would be 40 GB.

Now I need Mounir and ikkhares to comment as to:

1) whether it is agreed that a maximum operating system volume size of 40 GB is acceptable, and

2) how much time VeraCrypt currently takes to decrypt a 40 GB bootup volume

assuming of course that my conjecture above is correct :)
Jan 11, 2015 at 10:37 PM
ikkhares wrote:
Please excuse me for that, but I do not wish to bring this discussion to a personal level.
.
What seems unfair to me is you unjustly throw an accusation like that around.

If you want to debate the security of VeraCrypt I am here for you. I have been firm but fair.

The only question that needs answering for this thread to come to an end is.....

How does reducing the iterations in VeraCrypt improve security ? Bearing in mind long passwords should be employed anyway.
Jan 11, 2015 at 10:41 PM
L0ck wrote:
Many times I have explained on this thread that having the option for the user to increase iterations from the current default is a good thing. The problem is when you intentionally REDUCE the number.
The freedom to choose is important to me. I don't need that high literations number. It's overkill in my case. I'm not being hunted by NSA, I'm not paranoid.
If 30 seconds is too expensive for the level of security you require then VeraCrypt is not the application for you.
Over a minute for Athlon 64 3000+ is too much. TrueCrypt is dead and buggy, CipherShed is still pre-alpha. Other apps like BitLocker? No, thanks.
Let VeraCrypt be old-hardware-friendly!
Jan 11, 2015 at 10:46 PM
Edited Jan 11, 2015 at 10:47 PM
commenter8 wrote:
Now I need Mounir and ikkhares to comment as to:

1) whether it is agreed that a maximum operating system volume size of 40 GB is acceptable, and

2) how much time VeraCrypt currently takes to decrypt a 40 GB bootup volume

assuming of course that my conjecture above is correct :)
.
I don't think that b) stands true, but fyi we use 150 GB boot volumes for non-ssd drives and 120 GB / 180 GB boot volumes for ssd (full ssd size).
I will get back to you with the bootup time of a recent hw with ssd tomorrow.
Jan 11, 2015 at 10:49 PM
Mrere wrote:
The freedom to choose is important to me. I don't need that high literations number. It's overkill in my case. I'm not being hunted by NSA, I'm not paranoid.
.
You don't have to be hunted by the NSA to need good security, are you aware of how fast domestic hackers can test hashes with humble systems ? Reducing the iterations makes you vulnerable to this type of attack.
Over a minute for Athlon 64 3000+ is too much.
.
Wow another person who leads a very busy life. Really over a minute is too much to ask for security ? If this is true then you don't place much importance on the security of your files. That's fine, use something else.
TrueCrypt is dead and buggy, CipherShed is still pre-alpha. Other apps like BitLocker? No, thanks.
.
As you have already admitted you don't need strong security, any of those you mentioned will meet your needs.

Perhaps you might be able to answer this, no one else has....

How does reducing the iterations in VeraCrypt improve security ? Bearing in mind long passwords should be employed anyway.
Jan 11, 2015 at 11:09 PM
Edited Jan 12, 2015 at 7:42 AM
L0ck, you may take this personally - you have a misplaced notion that increasing the KDF iteraion imparts greater security.
It does not for strong passwords. Now I can use your style of argument and say that if you don't know how to create and use strong passwords, maybe any crypto program is not is for, lest you want a false sense of security.

For people who don't really understand password entropy, exhaustive search over a key space, or dictionary attack, long iteration count would certainly help. So basically they pay with their time for their igonarance. On the other hand, people who do understand those things would like to have a choice. We truely would.
Jan 11, 2015 at 11:10 PM
Edited Jan 11, 2015 at 11:18 PM
Using SSD presents its own security concerns! See "SSD security: the worst of all worlds" - http://www.zdnet.com/article/ssd-security-the-worst-of-all-worlds/ Fortunately, the commenters point out that Full Drive Encryption using TrueCrypt will compensate for SSD's problems :)
Jan 11, 2015 at 11:18 PM
Yes, I know, but that's a different security vs usability debate.

E.g.:
https://veracrypt.codeplex.com/wikipage?title=Trim%20Operation
https://veracrypt.codeplex.com/wikipage?title=Wear-Leveling

Also performance suffers greatly under full drive encryption with ssd drives, we benchmarked new drives.
Jan 11, 2015 at 11:26 PM
L0ck wrote:
Reducing the iterations makes you vulnerable to this type of attack.
I use strong passwords. I don't need that high number of iterations.
Wow another person who leads a very busy life. Really over a minute is too much to ask for security ? If this is true then you don't place much importance on the security of your files. That's fine, use something else.
My files are secure enough. I'd like to stay with VC.
As you have already admitted you don't need strong security, any of those you mentioned will meet your needs.
I need strong security, I just don't need paranoid level of security.
Perhaps you might be able to answer this, no one else has....

How does reducing the iterations in VeraCrypt improve security ? Bearing in mind long passwords should be employed anyway.
Does it? A strong password and some reasonable number of iterations. That's what I like to have.
Jan 11, 2015 at 11:46 PM
ninveh wrote:
L0ck, you may take this personally
.
I couldn't care less, I'm not that sensitive :) I accept a robust debate, it's all part of thrashing these problems out.

.
you have a misplaced notion that increasing the KDF iteraion imparts greater security.
.
I understand fully what iterations do, I have spent around 5 years on the other team so to speak.

.
It is not for strong passwords.
.
It is for all passwords, not having iterations really does open up the possibilities for an attacker, even for long ones.
Now I can use your style of argument
.
You failed to do it convincingly, you need a certain charisma. :D [joke]

.
if you don't know how to create and use strong passwords, maybe any crypto program is not is for, lest you want a false sense of security.
.
Determining a long "good" password is hard to do, it is not something which should be left to chance. Assuming a long password is strong enough to reduce iterations, is the real false security.

I get you point though, but it does not excuse weakening the iteration count. Iterations hurt attackers, a lot. It makes things VERY expensive.
For people who don't really understand password entropy, exhaustive search over a key space, or dictionary attack, long iteration count would certainly help. So basically they pay with their time for their igonarance.
I understand what you are saying but as I have repeated many times, VeraCrypt should not go back on it's founding principles. Users here are asking for VeraCrypt to solve or ease their impatience, the request has nothing to do with increasing security. VeraCrypt should not yield to users who demand immediate access to their files. If they want security, it comes with a price.
On the other hand, people who do understand those things would like to have a choice. We truely would.
You are missing an important point, time an attacker spends on other peoples drives is less time spent attacking mine. If everyone had a minimum iteration count as the default is now, then we all benefit.

Users who are too impatient to wait a minute for a drive to boot are not going to type a long "good quality" password.

Perhaps you can have a go at my question please ? No one has been able to get round it, answering it conclusively would be the thread killer :)

How does reducing the iterations in VeraCrypt improve security ? Bearing in mind long passwords should be employed anyway.
Jan 11, 2015 at 11:54 PM
Mrere wrote:
I use strong passwords. I don't need that high number of iterations.
.
As explained in other replies, determining "strong" is not easy. What is the longest random password you can remember without writing it down ?
My files are secure enough. I'd like to stay with VC.
.
Why try to drag down something that is beyond your security needs simply to suit yourself ?
I need strong security, I just don't need paranoid level of security.
.
Then you are forcing me to repeat myself. Any of the other applications will suit your needs. I don't see why you insist on trying to reduce VeraCrypt to your level.
A strong password and some reasonable number of iterations. That's what I like to have.
.
Please see my previous answer.
Jan 11, 2015 at 11:59 PM
The original suggestion that the number of iterations be stored in a text file is IMO not a good one, since attackers could very easily read it and profit from it.

A better way would be to provide a selection tool on the volume mounting screen. And rather than selecting a specific number of iterations, it would be better to provide a selection between various strength levels such as (Low, Medium, High, Ultimate). The selected strength level would result in a number of iterations that is dependent upon the version of VeraCrypt. For example. a VeraCrypt 1.0g volume might use a range from 500,000 on Low to 4 million on Ultimate, whereas VeraCrypt 1.0h volumes might use 2 million on Low and 32 million on Ultimate. The default strength level could be set to High. If the passphrase fails, users should be prompted to check both the passphrase they typed in and the strength level they have selected, since a passphrase will only work if the selected strength level is also correct.
Jan 12, 2015 at 12:06 AM
commenter8 wrote:
A better way would be to provide a selection tool on the volume mounting screen. And rather than selecting a specific number of iterations, it would be better to provide a selection between various strength levels such as (Low, Medium, High, Ultimate). The selected strength level would result in a number of iterations that is dependent upon the version of VeraCrypt. For example. a VeraCrypt 1.0g volume might use a range from 500,000 on Low to 4 million on Ultimate, whereas VeraCrypt 1.0h volumes might use 2 million on Low and 32 million on Ultimate. The default strength level could be set to High. If the passphrase fails, users should be prompted to check both the passphrase they typed in and the strength level they have selected, since a passphrase will only work if the selected strength level is also correct.
.
Yes this was the original idea, I think it has also been suggested on sourceforge.

I have no problem with it, my concern throughout this thread and e-mails is the lower threshold, it should be the current default.

VeraCrypt should only be concerned with security, people needing to solve or ease their impatience issues should seek help elsewhere. :)
Jan 12, 2015 at 12:58 AM
I just did some calculations and the security gain from going to UniCode is phenomenal!! Let's assume that VeraCrypt is based on the 65,536-character "Basic Multilingual Plane" as defined here: https://en.wikipedia.org/wiki/Plane_(Unicode). Since the current ASCII base contains only 128 characters, this results in 512 times as many possibilities per character position. VeraCrypt currently recommends passphrases of at least 20 characters; that corresponds to 1.4 x 10 to the 42nd power possibilities. Thus a UniCode BMP passphrase of only 9 characters (2.23 x 10 to the 43rd power possibilities) is 16 times stronger than a 20-character ASCII passphrase. A 20-character UniCode BMP passphrase contains 2.14 x 10 to the 96th power possibilities, which is 1.53 x 10 to the 54th power times the strength of a 20-character ASCII passphrase.
Jan 12, 2015 at 6:53 AM
Could we please have a civilized discussion here? Personal attacks like "pathetic paranoid" and "cyberbully" are not helpful here. L0ck is advocating a hard line on security. That's a legitimate viewpoint. It seems to me that L0ck may go too far by insisting that a long user delay is necessary, though. If security can be vastly increased by substituting UniCode's Basic Multilingual Plane for ASCII, then we can all enjoy much stronger protection AND much faster response time. Medicine does not have to have a bitter taste in order to be effective. Let's cooperate peacefully to make VeraCrypt both stronger and more beautiful at the same time!
Jan 12, 2015 at 6:54 AM
Edited Jan 12, 2015 at 6:55 AM
(Deleting duplicate post)
Coordinator
Jan 12, 2015 at 8:36 AM
I join commenter8 in asking participants to avoid personal attacks.
VeraCrypt community is made of people coming from different backgrounds and as such there always will be disagreements on the handling of security aspects. As such, this discussion must not become a words battle targeted towards specific people.
L0ck approach may seem exaggerated to some but it represents the point of view an important part of VeraCrypt users and it is inline with the conservative approach adopted by VeraCrypt since the beginning.
The other side which advocates more flexibility and usability has also good arguments that must be looked at since it is not always synonyme of reducing security.

As a moderator, my role is to ensure that the discussion remains productive. I personally learn a lot through this exchange of ideas and I would like everybody to expose its arguments in the most professional way without trying to impose any point of view.

This discussion is still open as I try to come up with even better solutions that could answer the expectations of most users without any security sacrifices.

Jan 12, 2015 at 8:43 AM
Edited Jan 12, 2015 at 9:55 AM
commenter8 wrote:
The original suggestion that the number of iterations be stored in a text file is IMO not a good one, since attackers could very easily read it and profit from it.
Knowing the number of iterations is not considered a security flaw. Both the original TC, as well as VC, have a fixed number of iterations known to all. The same with many other security products that are consider secured. The only thing that supposed to be a secret is the password (paraphrasing Kerckhoffs' principle).

Regarding your Unicode proposal: yes, it does increase the keyspace substantially. However, many are hesitant to implement it into their code because of issues of national keyboards and computer code pages. If a program implements Unicode PW input, it should be done with ample warnings for the uninitiated, and be ready to field many support questions from users who are locked out of their volume when using a foreign computer.
Jan 12, 2015 at 9:27 AM
Quoting from https://en.wikipedia.org/wiki/Unicode_input -
~~~~~
Microsoft Windows has provided a Unicode version of the Character Map program (find it by hitting ⊞ Win+R then type charmap then hit ↵ Enter) since version NT 4.0 – appearing in the consumer edition since XP. This is limited to characters in the Basic Multilingual Plane (BMP). Characters are searchable by Unicode character name, and the table can be limited to a particular code block.

Mac OS X provides a "character palette" with much the same functionality, along with searching by related characters, glyph tables in a font, etc. It can be enabled in the input menu in the menu bar under System Preferences → International → Input Menu (or System Preferences → Language and Text → Input Sources) or can be viewed under Edit → Special Characters... while Finder is in the foreground.

Equivalent tools – such as gucharmap (GNOME) or kcharselect (KDE) – exist on most Linux desktop environments.
Jan 12, 2015 at 9:38 AM
L0ck wrote:
As explained in other replies, determining "strong" is not easy. What is the longest random password you can remember without writing it down ?
I use the catch phrases tweaked with some special characters and numbers. They are long (over 20 chars) and easy to remeber.
Why try to drag down something that is beyond your security needs simply to suit yourself ?

Then you are forcing me to repeat myself. Any of the other applications will suit your needs. I don't see why you insist on trying to reduce VeraCrypt to your level.
My level is not mandatory for other folks. The lower iteration count should be optional. Something like: "Use at your own risk!", a hidden feature, etc. This optional thing won't harm your security level.
Jan 12, 2015 at 9:55 AM
International Components for UniCode - http://site.icu-project.org/

ICU is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software.

ICU is released under a nonrestrictive open source license that is suitable for use with both commercial software and with other open source or free software.
Jan 12, 2015 at 12:24 PM
Dear all,

As promised just a quick comment with a timing:
For a modern business laptop ( Intel Core i5-3320M 2.60Ghz, Intel 180 GB ssd ) it took 86 seconds to start booting after hitting enter for the passphrase.
Jan 12, 2015 at 1:04 PM
mtpagkatipunan wrote:
My previous post here is clearly addressed to Mr. Idrassi, I am expecting Mr. Idrassi to comment
.
If you demand a private audience with Mounir you should e-mail him, not write on a public forum.

.
paranoid L0ck
.
If wishing the best security for VeraCrypt is paranoia, then I am paranoid and proud of it. LOL

.
L0ck who is always shunning out the suggestions of other users of VeraCrypt.
.
Actually if you read the forum I always back and encourage good suggestions, it's the bad suggestions I challenge.

.
However, based on your posts L0ck and the way you behave in this forum, You have proven yourself not only just an extreme paranoid, but a cyberbully as well. In every section of this forum, you are always forcefully injecting what you have in mind.
.
Just because I disagree with peoples suggestions does not mean I am bullying them. Quote where I have threatened, used swear words or or made direct personal threats. You owe me an apology for this false statement.

.
You have no intention of accepting other suggestions, except only those that are coherent with your thinking.
.
That's called a debate, you push your idea's forward and challenge the security of other suggestions. If you wish to dictate your ideas, unchallenged, you are on the wrong forum using the wrong product.

.
Surely, everyone here have no intention of "dragging VeraCrypt down to the level of other products", nor we want VeryCrypt to become weak.
.
They may be doing so unintentionally, in which case it is lucky there are a few here who point it out.

.
As Mr. Ikhares commented on your behaviour:
What seems unfair to me is you unjustly throw an accusation like that around.
.
Again more deception from you, you have attempted to sneak in a misquote and pretended it was addressed to myself. The quote is actually mine !!! LOL

.
Why don't you let Mr. Idrassi comment on the suggestions and let him ultimately decide on what to do.
.
I have never said he couldn't. Can you quote me where I have said otherwise ?


You are of the opinion your suggestions must go unchallenged, you have made false allegations towards myself and I have caught you deliberately misrepresenting quotes.

You have been exposed, you owe me an apology.
Jan 12, 2015 at 1:05 PM
Mrere wrote:
I use the catch phrases tweaked with some special characters and numbers. They are long (over 20 chars) and easy to remeber.
.
This was my point, many people believe catch phrases, even with tweaks are secure. Honestly you have to believe me they are not. Crackers have word lists with quotes, sentences and words which are from books, songs and poems etc. Tweaks are added with "rules". These sorts of passwords are broken, especially with low iterations.

My whole argument on this thread has been if you reduce the iterations you expose users who believe they have a long, good quality password to attacks. I trust Mounir will make the best job he can but filtering for these weak passwords will be almost impossible.

So this is why I am shouting as loud as I can to warn everyone on this thread, reducing iterations is a bad idea because unless you use a very long totally random password you will weaken security. This will be the first time since conception Mounir has gone in this direction with VeraCrypt, mainly to stop impatient users nagging him.

This feature is not a security enhancement, it is detrimental and although you are someone who is arguing for the new feature, your post about passwords has rather proved my point. I am not making fun of you, it is a genuine concern.

.
My level is not mandatory for other folks. The lower iteration count should be optional. Something like: "Use at your own risk!", a hidden feature, etc. This optional thing won't harm your security level.
.
I understand this, but we have to think about VeraCrypt and humble, unaware users also. As you have demonstrated, users have no idea of what a secure password is, they will have a false sense of security. Again I am not picking on you, you have at least been honest about your password strategy. I am certain many others on this thread were of the same opinion but they will not dare admit it now, so you are not singled out here.

VeraCrypt should be a safe tool to use for everyone. Everything should be done to protect the user from themselves. If anyone still insists that speed is more valuable than security then there are other products.

If they will not accept other products then I see no reason why they would object to using VeraCrypt Lite, why interfere with VeraCrypt full ?

I guess I need to make things very clear on this thread as some other members are very sensitive, I am not bullying you or belittling you in any way. However your post has been more help to my point than anything I could have written myself.

Mounir, I hope you have read this one :) As you can see users will have a false sense of security by using predictable passwords. No one is going to be able to remember a 30+ random character string. A drop in iterations will weaken VeraCrypt, I understand you must be tired of people nagging about boot times etc, I have made a suggestion that they try another product or perhaps VeraCrypt Lite. I have not seen a good reason to drop iterations on this thread other than to appease users impatience, which I believe is out of the scope of VeraCrypt's development.



To ALL

If I was a selfish bully, I would sit back and laugh at those requesting they are allowed to reduce their security. I am actually concerned you guys don't realise what you are asking for. I know Mounir is of the same opinion as myself, but what do we do ?

It is the same analogy I used before, with parents giving their children sweets all the time. It may make the parents popular but it does no good for the children’s health.

Those with staff may believe these impatient users will come up with long totally random passwords, but if they are the type to be impatient, they are unlikely to be bothered to memorise or type a good password. You are under a false impression of what a good password is and high iterations will protect you.

Adding this feature has no impact on Mounir's or my personal protection, I have spent a lot of time warning others what they are doing or asking for is wrong, if that makes me a bully then so be it. However ask yourselves about my motivation, if this has no impact on my security, why would I spend so much time trying to protect everyone else if I was such a bad person ?
Jan 12, 2015 at 4:02 PM
L0ck,
My passwords are broken. Really? You haven't seen them. I gave you just basics. Maybe you have good intentions, but I really don't need your protection.
Jan 12, 2015 at 4:49 PM
Mrere wrote:
My passwords are broken. Really? You haven't seen them. I gave you just basics.
.
You provided the method you used to make them which was enough. There is no need to be embarrassed or defensive, you are a typical user and I am grateful you were honest enough to explain your password creation method.

Your post was very helpful, I have PM'd Mounir and directed him to it. I wanted him to see what this feature request to reduce iterations would lead to. A dangerous false sense of security, until now you believed that method was strong did you not ?

You are not alone, I have done this with other members on the forum with similar results. I had to use real world users like yourself to make the point. I have also sent those links to Mounir, so you have not been singled out.

.
Maybe you have good intentions, but I really don't need your protection.
.
I do have good intentions which should be clear if people took the time to think about my points and motivation.

You say you "don't need my protection", well I hope you learned something from this example.
Jan 12, 2015 at 7:19 PM
L0ck,
Once again, you haven't seen my passwords. They are way more complicated than something like Hasta 1a vi5ta, baby!.
Jan 12, 2015 at 8:32 PM
Mrere wrote:
Once again, you haven't seen my passwords. They are way more complicated than something like Hasta 1a vi5ta, baby!.
.
You are forcing me to repeat my answer.

You provided the method you used to make them, which was enough.

.
I use the catch phrases tweaked with some special characters and numbers.
.
If you use passwords based on this simple technique with a low iteration count you are reducing the ability for VeraCrypt to protect your files.

You are precisely the user the higher iteration count is there to protect. I am sorry for using you as an example to prove my point, but there just are not enough members on the forum yet.
Jan 12, 2015 at 8:58 PM
L0ck,
Do you think that long personal catch phrases with some random characters are easy to crack? If yes, prove it. I can send you a small TrueCrypt file container to crack it.
Jan 12, 2015 at 9:02 PM
L0ck wrote:
Mrere wrote:
Once again, you haven't seen my passwords. They are way more complicated than something like Hasta 1a vi5ta, baby!.
.
You are forcing me to repeat my answer.

You provided the method you used to make them, which was enough.

.
I use the catch phrases tweaked with some special characters and numbers.
.
If you use passwords based on this simple technique with a low iteration count you are reducing the ability for VeraCrypt to protect your files.

You are precisely the user the higher iteration count is there to protect. I am sorry for using you as an example to prove my point, but there just are not enough members on the forum yet.
L0ck I admire your persistence in keep trying to explain it. But I don't think it will be understod by the "average" user.
Jan 12, 2015 at 9:21 PM
ikkhares wrote:
Dear all,

As promised just a quick comment with a timing:
For a modern business laptop ( Intel Core i5-3320M 2.60Ghz, Intel 180 GB ssd ) it took 86 seconds to start booting after hitting enter for the passphrase.
OK, and for a good user experience the delay should be no more than 10 seconds (quoting your answer earlier), so a factor of 10 speedup is needed.

TrueCrypt used 1,000 iterations and VeraCrypt is using 327K+. If the VeraCrypt number is reduced by a factor of 10 then that's still 32,700 iterations.
Jan 12, 2015 at 9:32 PM
destrukt wrote:
L0ck I admire your persistence in keep trying to explain it. But I don't think it will be understood by the "average" user.
.

LOL Thank you destrukt, I do my best :)
Coordinator
Jan 12, 2015 at 11:38 PM
I think this thread has become a little too long and a little boring as there is less and less useful information coming out of it.

It is normal to have a heated debate but it is not productive to loose energy in a war of words. Thus, I would like users to stop posting to this thread unless something different and new is expressed. So far, proponents and opponents have given their arguments and I'm not expecting any global agreement.
Jan 13, 2015 at 8:59 AM
Edited Jan 13, 2015 at 9:16 AM
idrassi, that's the reason that I've thought to stop contributing to this specific thread - the expressed opinions kind of exhausted themselves.
However, you asked to post only something different and new, so this may be it:

NIST, who sets the standards for US government and participating industry has some recommendations on the matter.
  • NIST Special Publication 800-132 - Recommendation for Password-Based Key Derivation. Part 1: Storage Applications -
See Paragraph 5.2 "The Iteration Count" and the actual recommendations in A.2.2.

tl;dr: For laptop cold boot process, they recommend a KDF that may delay the boot process by one second or so.

This recommendation may give a fit to some forum participants, but regardless it establishes a frame of reference for an encrypted and secured system.

http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf


Edit: in the acknowledgements of the above publication, NIST mentions that they have consulted some experts in this field, and I thought that having consulted John Kelsey, who worked hand-in-hand with Bruce Schneier some years ago and lately headed the SHA 3 hash competition, is worth noting.
http://csrc.nist.gov/staff/rolodex/kelsey_john.html
Jan 13, 2015 at 9:06 PM
I think the only new information we need to see on this thread is any evidence to contradict the following.

People here asking for VeraCrypt to weaken iterations are doing so only to placate their impatience, the request has nothing to do with increasing security.

Mounir has stated he shares my point of view on this subject, however he wishes to make VeraCrypt more popular.

Mounir has suggested a compromise of password length to iteration count to please these people. As I have demonstrated on more than one member here, most users have a poor understanding of what a good password is.

Length is not a guarantee of strength, so this leaves quality. Writing code to check for the quality of a password will be very hard and I will fill Mounir's in-box with bug reports of accepted weak passwords if he tries to make one :)

For Mounir to comply with this demand he will have to go back on his original principles for VeraCrypt which was to focus on increasing security only.

What we are witnessing and testing in this thread is the strength of Mounirs character, it is not a battle of security principles, as that battle has been won.

All evidence is clear within this thread, the secure way forward is easy to see. The uncertainty is will Mounir's stay true or yield to pressure from those either not requiring real security, or simply misunderstanding it.

If he breaks this principle so early in VeraCrypt's development, one has to wonder what other principle may be broken at a later date. Trust is very important when choosing an encryption product and this could kill VeraCrypt's reputation dead.

So Mounir, is VeraCrypt 100% about security or will you make compromises to be more popular amongst the less security aware, or simply impatient public ?

LOL :P Sorry to do this to you Mounir, when in a debate for the defence of VeraCrypt, all is fair and I am prepared to fight dirty LOL :P [joke]

I guess this Kind of drops you in tight spot :) :p
Coordinator
Jan 13, 2015 at 11:26 PM
It is not easy to close this topic ;-)
First, thanks ninveh for brining the NIST position on this. My personal opinion is that it is wrong to use the machine benchmark for KDF performance as a basis for fixing the KDF complexity. An attacker will most certainly not use the user's machine to perform his attack and we have to suppose that he can have access to a parallel brute force infrastructure on the cloud or using dedicated hardware. So, the 1 second value given by NIST has no value from the security point of view without being attacked to some other parameters and I doubt that experts like John Kelsey or Bruce Schneier will endorse this.

Concerning L0ck comment, security is the paramount objective of VeraCrypt. Indeed, I would like to make VeraCrypt more accessible to a larger audience but I want to do this without losing VeraCrypt guarantees about security. Maybe at the end I will go back to the idea of creating a "VeraCrypt Lite" in order to clearly separate between the two approaches.
Jan 13, 2015 at 11:55 PM
idrassi wrote:
Concerning L0ck comment, security is the paramount objective of VeraCrypt. Indeed, I would like to make VeraCrypt more accessible to a larger audience but I want to do this without losing VeraCrypt guarantees about security. Maybe at the end I will go back to the idea of creating a "VeraCrypt Lite" in order to clearly separate between the two approaches.
Mounri, your integrity remains intact !! :D

You have demonstrated you will remain steadfast in your principles.

The true security minded users will be reassured VeraCrypt will ALWAYS place security above all else.

As for VeraCrypt Lite, I suggest as commercial users want this feature, they could perhaps offer to contribute to the project, certainly enough to cover your time to make the separate build.

There is a thread where just how much weakening of VeraCrypt Lite can be discussed here... https://veracrypt.codeplex.com/discussions/577405


Congratulations Mounir, I am proud of you. :)

Vive La VeraCrypt !!!!
Jan 14, 2015 at 6:38 AM
A separate build because of paranoia. What a bright idea! :-/
Jan 14, 2015 at 12:46 PM
Mrere wrote:
A separate build because of paranoia. What a bright idea! :-/
.
VeraCrypt was created out of "paranoia" that all other encryption programs were not secure enough.

To truly understand the term paranoid you must first be able to comprehend the threat model. You were not able to demonstrate you had.

Anyway cheer up, you will be able to enjoy faster boot times with the less secure Lite version. I should have thought you would have taken the opportunity to say thank you to Mounir for providing this for you. It is an example of your character that you decided to insult instead.

You can also take comfort in the fact Mounir has demonstrated he will not yield to nagging to weaken VeraCrypt, however persistent and petulant it is.

All users can feel less "paranoid" as they can see Mounir will not compromise when it comes to VeraCrypt's security, thousands who use VeraCrypt will be very pleased.
Jan 14, 2015 at 1:21 PM
Edited Jan 14, 2015 at 1:24 PM
idrassi, several comments if I may:
  1. The idea of 2 separate builds will eventually come to haunt you. The constant need to maintain two separate builds, especially under time pressure if some security flaws are found should not be taken lightly. I know of a couple of big corporations who unified their build offerings because the support effort, the testing and the book-keeping of 2 different distributions weren't worth it.
  2. I agree that number of iterations need to be considered in conjunction of other parameters, as PW strength and speed of machine, but as you don't force minimum PW parameters on the user in order to have as high security as possible...
  3. Bruce Schneier developed the open source PasswordSafe program to keep various PWs under one secure master password. This is the "sanctum sanctorum" of all things secret. That program, freely available from sourceforge, has a user definable iteration count for unlocking the safe (in Manage/Options/Security menu).
    (as another participant mentioned, Keepass has also user-definable iteration count. That program is also considered very secured)
https://www.schneier.com/passsafe.html
http://passwordsafe.sourceforge.net/

From the keepass FAQ page at http://keepass.info/help/base/security.html

"By default, KeePass sets N to 6000 encryption rounds (full encryptions are meant; N has nothing to do with the internal encryption rounds of AES). This number has been chosen in order to provide compatibility with portable device versions (PocketPC processors are slower, therefore the key computation takes longer).

If you are using KeePass on PC only, it is highly recommended to increase the number of key transformation rounds. You can change the number in the database options dialog. Right of the field for the rounds, you'll find a button. When clicking this button, KeePass computes the rounds number that leads to a 1-second delay. Waiting 1 second at database opening isn't a problem, but for an attacker of course it is. But, the number can be freely set to a number of your choice; the button only should give you a rough idea how many rounds can be computed in 1 second on your computer.
......
KeePass uses multithreading to compute the transformations (the master key is split up to two parts of 128 bits, which is the AES block size). On dual/multi core processors, the computation can be twice as fast as on a single core processor.

On Windows Vista and higher, KeePass can use Windows' CNG/BCrypt API for the key transformations, which is about 50% faster than the KeePass built-in key transformation code."
Jan 14, 2015 at 1:28 PM
Developing some lite version means wasted resources. I'm staying with VeraCrypt for now. Maybe CipherShed will be better...
Jan 14, 2015 at 3:03 PM
ninveh

It was not the option to allow user definable iterations which was the security risk. It was the minimum allowable.

Making user definable iterations is fine, as long as the current default is the minimum.

Your post refers to a different issue than the one being discussed here.

I would prefer it if you could stay on subject or at least start a new thread with this new request. Actually it is one I would support.
Jan 14, 2015 at 3:04 PM
Mrere wrote:
Developing some lite version means wasted resources. I'm staying with VeraCrypt for now. Maybe CipherShed will be better...
.
I am pleased you have accepted your request will ultimately waste resources, something we wished to avoid.

Yes I agree and have constantly been telling you CipherShed is probably more suitable for users such as yourself.

Constantly whimpering on this thread after the decision has been made to maintain VeraCrypts integrity will not further your campaign.
Jan 14, 2015 at 5:10 PM
L0ck, dude you an attorney or something? lol

i read this thread every day and laughed at how you handled these guys.

i never felt teh need to chip in because your were doin fine on your own!

right decision was made in teh end, you did right bro and mounir too.

veracrypt should stay strong, weakening only adds fear and uncertainty in an otherwise top proggy

peace n congrats on your win ;)
Jan 14, 2015 at 6:14 PM
L0ck wrote:
I am pleased you have accepted your request will ultimately waste resources, something we wished to avoid.
Scrap the lite version, just start advertising VC as a tool for paranoics and self-proclaimed "security experts". This will make things clear.
CipherShed is probably more suitable for users such as yourself.
I hope so. Just don't spill your paranoia there. Or maybe you should? That may be funny.
Constantly whimpering on this thread after the decision has been made to maintain VeraCrypts integrity will not further your campaign.
Thanks for the tip.

Cipher1 wrote:
i never felt teh need to chip in because your were doin fine on your own!
Too bad, this thread would be a lot better with more of that lame slang.
Jan 14, 2015 at 6:30 PM
Something different and new - Mounir refers to "VeraCrypt guarantees about security" - are these guarantees precisely defined, and if so how?

IMO the "VeraCrypt guarantees about security" should be expressed in terms of how difficult it makes the life of the attacker, not in terms of how difficult it makes the life of the user.

If the minimum difficulty for the attacker can be preserved (or raised) while also increasing the convenience of the user, then that should satisfy the "VeraCrypt guarantees about security".

Rebasing VeraCrypt on the UniCode Basic Multilingual Plane (see https://veracrypt.codeplex.com/workitem/62), in conjunction with a reduction in iterations to 32,000 (which is still 32 times stronger than the iterations of TrueCrypt) would have the net effect of very greatly increasing the difficulty for the attacker while also reducing the user delay to only 10 seconds. And an entertaining and informative user display (see https://veracrypt.codeplex.com/workitem/59) would ensure that the user would not mind waiting the 10 seconds.
Jan 14, 2015 at 6:53 PM
commenter8,
nice idea, but it's too reasonable. That's not how they roll.
Jan 14, 2015 at 7:36 PM
Edited Jan 14, 2015 at 7:51 PM
Cipher1

Thank you for your kind words.

I wasn't making fun of them, or even laughing at them myself. It is not reasonable to expect everyone to know these issues.

No I'm not an attorney (solicitor or lawyer here in England), I simply stuck to the facts, which are hard to defeat.

Thank you for your support though.
Jan 14, 2015 at 7:38 PM
Mrere wrote:
Scrap the lite version, just start advertising VC as a tool for paranoics and self-proclaimed "security experts". This will make things clear.

I hope so. Just don't spill your paranoia there. Or maybe you should? That may be funny.

Too bad, this thread would be a lot better with more of that lame slang.

nice idea, but it's too reasonable. That's not how they roll.
.
Mrere

You are far from honourable in defeat.

We can clearly see you true personality coming through now. You have done nothing but make personal attacks recently, not limited to myself. It is obvious you feel deeply hurt, do you have someone off-line who might be able to console you ?

I also found it interesting you demanded VeraCrypt had an ability to weaken iterations, when a solution was presented to you "VeraCrypt Lite" you seem to have rejected it. Strange why you are still persistent in your efforts to directly affect VeraCrypt full version.

You may feel better continually trolling and insulting the users and VeraCrypt in general and also claiming everything is based on inordinate paranoia. However your insults will have no effect on the security of VeraCrypt or your plea to weaken it.

It seems to me that you are too paranoid to use another product.
Jan 14, 2015 at 7:41 PM
commenter8

I know the implementation of UniCode is very important to you, you have brought the subject up before. I have even voted for it at your request.

The decision about iterations has been made, VeraCrypt Lite will be more suitable for you. Perhaps even CipherShed will offer a weaker iteration count to appease home users.

As this subject has been concluded many posts above, I think it would be best if we allow Mounir the last word, the quote below is a thread killer and I wish he had posted it here earlier.


Mounir Wrote:
1 second on your machine my become 0.1 second on a more powerful machine and it can become 0.0000001 second on a parallel brute force infrastructure on the cloud. If an attacker want to decrypt your drive/volume, he will not use your machine!

Choosing the iterations count depending on the time taken on the user machine is wrong. It creates a false sens of security. When you define security parameters, you try to assess the capabilities of potential attackers and this starts by supposing that they have access to better hardware/infrastructure than you.
Jan 14, 2015 at 8:03 PM
L0ck, that quote was written before I pointed out that with UniCode it is possible to overwhelm the capabilities of attackers in another way. The great increase in security from that advance removes any need to think of iterations as the only way to provide increased security. Now that the security pressure has been removed from the iteration count, other factors can be considered. If users find 10 seconds to be the highest acceptable delay, then VeraCrypt is now free to select the iterations count accordingly.

Also, I believe you have misinterpreted Mounir's words. Mounir wrote: "security is the paramount objective of VeraCrypt. Indeed, I would like to make VeraCrypt more accessible to a larger audience but I want to do this without losing VeraCrypt guarantees about security. Maybe at the end I will go back to the idea of creating a "VeraCrypt Lite" in order to clearly separate between the two approaches" - perhaps you missed the "Maybe"? When the word "Maybe" is used, that has a very different meaning than "Certainly". You are loudly assuming "Certainly" and disregarding the fact that "Maybe" is the word Mounir actually chose to use.

I agree with Mounir's stated goal of making VeraCrypt accessible to a larger audience without reducing its level of security, and UniCode makes that possible.
Jan 14, 2015 at 8:21 PM
UniCode may not be possible to implement.

You are also over estimating the users, those who are too impatient to wait for the iterations are unlikely to use good passwords including UniCode. I have been able to demonstrate peoples lack of knowledge regarding password strength on a forum populated by supposedly security aware users. Just imagine how the average home user trying to work this out.

I understand you hope I have misinterpreted Mounir's words, however this is not the only place we talk.

Why are you so resistant to using VeraCrypt Lite, is it because you don't like the name Lite ? Does it make you feel less secure or something ? VeraHome, VeraQuick version any better ?

I know Mounir does not really want the low iteration count version to damage the VeraCrypt name, so perhaps something other than "Vera" should be used for the weaker version.

CipherShed may cater for less secure needs when it is released, I don't think you should simply disregard it.
Jan 14, 2015 at 8:50 PM
UniCode has repeatedly proven itself and can indeed be implemented in VeraCrypt.

https://en.wikipedia.org/wiki/Unicode#Unicode_in_use

Unicode has become the dominant scheme for internal processing and storage of text. Although a great deal of text is still stored in legacy encodings, Unicode is used almost exclusively for building new information processing systems. ... Many major free mail providers such as Yahoo, Google (Gmail), and Microsoft (Outlook.com) support it. ... All W3C recommendations have used Unicode as their document character set since HTML 4.0. Web browsers have supported Unicode, especially UTF-8, for many years. ...

International Components for UniCode - http://site.icu-project.org/

ICU is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software.

ICU is released under a nonrestrictive open source license that is suitable for use with both commercial software and with other open source or free software.
Jan 14, 2015 at 9:04 PM
I hope you are right, I would welcome UniCode in VeraCrypt.

However you are discussing a separate feature request on the wrong thread.

Before you repeat yourself further, I understand you believe this will be adopted by inexperienced and impatient users to allow them to employ low iterations.

I have explained why this is not likely above.

I think Mrere and yourself are determined to constantly rehearse the same request regardless of any answer provided. You have been given other solutions and the offer of a Lite version of VeraCrypt which you both seem to have rejected, or at least not accepted.

If you both insist on repeating already defeated points I guess we will have to ask Mounir to close or even delete this thread, which would be a shame to all those who participated in it.

It would also be useful to point new members to in future as to why low iterations are unacceptable in VeraCrypt full.

I would encourage you to continue your request for UniCode on your UniCode thread. It is something I support but I am still unsure if it is possible to incorporate into the boot loader.
Jan 14, 2015 at 9:32 PM
The bootloader is being rewritten as 32-bit (not 16-bit as with TrueCrypt), and this will enable UniCode implementation.

Password strength is an important problem which is independent of both iterations and UniCode. At present VeraCrypt only looks at the length of the passphrase and issues a warning if the length is less than 20 characters. The vast majority of the cases in which attackers have succeeded against TrueCrypt have been directly attributable to weak password choices. No encryption software can protect you if your password is simply the first name of your spouse or some other easily guessed response. Many improvements to VeraCrypt's password examination process are possible and it is certainly important that such improvements be made.
Jan 14, 2015 at 9:38 PM
That's a very interesting post commenter8, it would be wonderful if it was posted in your UniCode thread.

Please don't encourage Mounir to delete this thread, a lot of people have contributed to it.
Jan 15, 2015 at 5:09 PM
Please provide user selectable KDF iterations.
Jan 15, 2015 at 5:19 PM
alidari6x wrote:
Please provide user selectable KDF iterations.
.
User selectable iteration counts will be provided, the minimum number however will not be reduced, for all the reasons posted above.
Jan 15, 2015 at 5:30 PM
L0ck wrote:
alidari6x wrote:
Please provide user selectable KDF iterations.
.
User selectable iteration counts will be provided, the minimum number however will not be reduced, for all the reasons posted above.
Some of us don't need that high number. Please don't discriminate us. Unrestrained selectable KDF iterations will be good for everyone.
Jan 15, 2015 at 6:06 PM
Edited Jan 15, 2015 at 7:37 PM
alidari6x wrote:
Some of us don't need that high number. Please don't discriminate us. Unrestrained selectable KDF iterations will be good for everyone.
If that is the case, then use TrueCrypt, Bitlocker, DiskCrypter... It do not make sense to use VeraCrypt if you don't need the security..
If you don't need a "secure" product, then use one of the above one's.. (That will aparently be enough for you)
Jan 15, 2015 at 7:22 PM
alidari6x

Read the thread, all opposition points were answered.

destrukt has provided you with the alternatives to suit your needs.
Jan 15, 2015 at 10:08 PM
Edited Jan 15, 2015 at 10:09 PM
I've created a new issue directly addressing the problem of user password selection:

https://veracrypt.codeplex.com/workitem/69

Please click on the link and upvote this proposed change - thanks! :)
Jan 16, 2015 at 6:41 PM
Does VC maximize use of multiple CPU cores to reduce the delay problem?
Some creative solutions may be possible to allocate this job to multiple workers.
Jan 16, 2015 at 6:59 PM
GeorgeWest wrote:
Does VC maximize use of multiple CPU cores to reduce the delay problem?
Some creative solutions may be possible to allocate this job to multiple workers.
.
Running in 32bit mode would be very helpful, this is the ticket everyone wanting faster boot times needs to vote for.

Link
Jan 16, 2015 at 9:01 PM
Hello, I'm new to this forum and I would like to propose a temporal solution for those who need speed:

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.
Jan 20, 2015 at 4:26 PM
Edited Jan 20, 2015 at 4:32 PM
For those who do not visit or are aware of the VeraCrypt forum on the SourceForge site, Mounir has made his decision regarding the Dynamic mode iteration feature.

I cannot create the hyper link. So copy-and-paste below into your browser.
https://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/?limit=25&page=2#107a
Jan 20, 2015 at 6:52 PM
Cross-posting Mounir's response; I corrected a typo in his last sentence.

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 bootloader optimization, this will take place afterwards.
Jan 22, 2015 at 2:00 PM
Clarification from Mounir:

I cannot properly create the hyper link to SourceForge due to the special characters being interpreted by the CodePlex forum software. So copy-and-paste below into your browser.
http://sourceforge.net/p/veracrypt/discussion/technical/thread/77d58591/?limit=25&page=2#8e6a
Coordinator
Jan 23, 2015 at 9:19 AM
Edited Jan 23, 2015 at 9:24 AM
Here is a shortened URL to my post: http://tinyurl.com/kssfpvj

(Codeplex handling of URLs is broken and my earlier attempt was wrong)
Coordinator
May 25, 2015 at 11:51 PM
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.

Thank you in advance for your tests and feedback.
May 27, 2015 at 8:56 AM
Original results from my comment above:
.
For a modern business laptop ( Intel Core i5-3320M 2.60Ghz, Intel 180 GB ssd ) it took 86 seconds to start booting after hitting enter for the passphrase.
.
Same machine, version 1.12-beta:
pin 1 --- ~1 sec
pin 10 -- ~11 sec
pin 50 -- ~43 sec
pin 100 - ~85 sec

Awesome work, thank you!
Jun 4, 2015 at 9:04 AM
Using the beta on one machine daily over a week for testing: no issues so far.
Dec 26, 2015 at 1:56 PM
L0ck, you spook the hell out of me. Do keep in mind that the CRYPT in VeraCRYPT comes from encryption and not from a religious context. This is only software.