Hello.
First thank you for continuing this project after the strange Truecrypt end.
I have a SONY VAIO laptop using now "Veracrypt 1.04d" instead of "Truecrypt 7.1".
I works well except that after input my password, it takes one minute to start booting Windows7 64bits.
Can you please help me to improve this delay ?
Thanks in advance.
F Malaterre
This delay is caused in part by the fact that we increased the iterations count to a level that gives us the best possible security while still being useable.
Another reason is that the encrypted partition doesn't contain any indication about the encryption algorithm for security reasons. So, in order to boot Windows, VeraCrypt tries all available encryption algorithms in sequential order (AES -> SERPENT -> TWOFISH -> TWOFISH+AES -> SERPENT+TWOFISH+AES -> AES+SERPENT -> AES+TWOFISH+SERPENT -> SERPENT+TWOFISH). Thus, if you choose an encryption algorithm that is in the middle if the list (for example AES+SERPENT), you will wait more time than if you choose AES only.
For that point, we are thinking about adding an entry in the boot menu to let the user select the correct encryption algorithm so that we can save time.
Last point : the code of VeraCrypt BIOS boot loader runs in a restricted environment with limited resources and legacy mode (16-bit), which make all cryptographic computation slower. Once Windows is started, we go back to normal more with no performance degradation.
We can do nothing about this. In the future, we plan to support UEFI boot which enables the use of more resources for booting.
As a summary, we can optimize only the case where an encryption algorithm other than AES is used by enabling the user to select the correct encryption algorithm directly instead of trying all combinations. If tests are OK, this could be included in the next release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-08-27
FYI... I chose AES, and just encrypted a 12 gig partition on the drive, NOT a system boot partition and it too takes noticeably longer to mount than with Truecrypt. BUT once mounted the files seem to process just as fast as Truecrypt's last version. I am going to start a second thread about some behaviors I have noticed.
-Sir.Roberte
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for this feedback.
Yes, the mount of a volume under VeraCrypt is slower than TrueCrypt because of the enhanced security of key derivation as explained in my post. As you pointed out, once mounted, read/write operations have the same performance as for TrueCrypt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-10-24
Everyone commenting on the slow speed, or how much longer VeraCrypt takes to open a container should actually see this as a positive !!! The longer it takes the genuine user to open the container with the correct password the better, just imagine how much harder it will be for the attacker !
Users just don't seem yo understand the benefits of this, which is disappointing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-06-18
Anything that degrades the performance of a pc is not a "Positive"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-10-27
hi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-10-27
Hello,
I had use the true crypt software but after stop service we have try vera crypt both installation as same as per my observation. i have getting issue when i insert password while booting it will take 40 sec to accept the password any idea how to decrease time or any option for fast booting. please reply
Thanks in advance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For those who prefer to have a fast boot, we are currently implementing a security level choice where the user can choose to have strong, medium or low security.
The low security mode will be the fastest and at the sametime it will be stronger than TrueCrypt (10000 instead of 1000).
We'll release a beta version that includes this feature soon, so stay tuned.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-11-19
Has this vesrion been released yet??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No and we don't think that this feature is going to be included after all. We had some exchanges about it with different users and it appears that it will add confusion about the real security level of VeraCrypt and it will also be a big departure from the spirit of TrueCrypt were all created volumes are assured of having the same level of security.
Moreover, as I always repeat, this delay affects only the boot time and not the performance once Windows is loaded, so it is worth waiting if you have really sensitive data that need this level of security.
A more important feature is to rewrite the bootloader in order to evade the limitation of the current 16-bit mode that makes the performance of the boot so poor. Once we have a 32-bit bootloader, the boot time will dramatically decrease without a need for decreasing the security of the encryption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-11-19
"we don't think that this feature is going to be included after all"
AWESOME !!! :)
I am really pleased to read that ! VeraCrypt is 100% security, no compromise :D
L0ck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-11-27
If the delay is too long on older systems and users have no alternative, one might argue they may not use it at all. While 'confusing the user' is one reason for omitting, it is certainly no more complex than remembering which keyfiles were used to protect a non-boot volume. If the choice of selecting hashing iteration levels at boot is added, adding a 4th paranoid level using 2x-5x more iterations than the high security level(and resulting in an even longer hashing delay) is equally attractive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-12-29
Hello, could you please implement this to give the user the option to boot faster. I have a relatively fast CPU 3700K OC 4.2Ghz, but authentication at boot up still takes up to 30 seconds. I have already spent days encrypting a few large volumes with veracrypt, and it will cost too much time to revert to truecrypt. Or at least please release a "sideline" version with this function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-12-29
Seriously, if 30 seconds is too much to ask then you have no need for this security product.
Your threat model is simply not significant enough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that for TrueCrypt users, booting using VeraCrypt would seem like an eternity but you can't have a fast boot and a good security level.
As I explained in different posts, reducing the key derivation complexity to make it as fast as in TrueCrypt is not the good answer. The objective of VeraCrypt is guarantee a minimal security level for the next 10 years and the key derivation complexity was chosen with that respect.
The real solution is to rewrite of the bootloader in order to switch to full 32-bit performance which will divide the boot time by a 2 or 3. This is part of the roadmap and it is the next objective of VeraCrypt.
I receive numerous request asking for the release of a version with faster boot (e.g. lower security) but I'm still not convinced if it is good on the long run.
Things may change in the future if I have or I received better ideas on how to implement such "security customization" without affecting VeraCrypt security targets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Stephen for this feedback and for your support.
Happy new year, wish you all the best.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-12-30
Ignore the detractors Mounir, aim for security only. People such as those above who need speed not security can use a less secure product, keep VeraCrypt for those who need real security.
Personally I think the full 32bit performance should perhaps be number 1 on your "to do" list :)
It will stop a lot of threads like this one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-01
Agreed. Ignore the detractors. You just never know who might be offering this type of advice/suggestion.
-EOM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-03
Please implement fast boot, I don't see any problem at all. People beeing confused of this function are too "confused" to use a secure password. Nobody would be confused at all.
As long as people can choose to use a high iteration then there is no problem. And no, I don't come from the NSA, I come from planet usability and with Windows I have to reboot a lot of times and was so happy that after my SSD and Windows 8.1 I can boot up in less than 15 seconds and now this problem comes up...
Let the people be free in their choice, freedom is dangerous but when giving up freedom for security you will loose both in th eend (probably not the wisest quote to use in this context, but it sounds cool and makes sense in the political context).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-10
Hey, you have to implement an option to use lower iteration, it can be still higher than TC but every user should be able to decide himself if he wants to get high bruteforce security or low bruteforce security, although the length of the password can completely eradicate the need of high iterations... so pleaaaaaaaase give us this feature!
At this point Veracrypt is unusable for my system partition which is really sad! Let the users decide if they want high iterations or not!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-10
"although the length of the password can completely eradicate the need of high iterations"
This is not necessarily true, your use of the word "can" saved you from ridicule.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-11
So why do you think it is wrong? When you have a 64 character password then there is no need for high iterations, cause bruteforcing even in realtime would take hundred of years and that includes progress in technology that we are able to foresee. It is more likely that AES 256 Bit can be defeated than the password...
So, I have nothing against high iterations but please, dear Mounir, implement the option of a lower iteration count like 10.000, that is still 10 times higher than the TC count! There are NO disadvantages of giving us this feature!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-13
It is wrong because most users are not aware of what a good password is.
Length is not a guarantee of strength. Some unskilled users think quotes, poems and song lyrics are good long passwords, they would certainly meet your criteria for length.
However crackers already have very large dictionaries which contain these lines. Rules are used to manipulate leet characters and add dates etc.
So as you can see, there is actually a very serious disadvantage to reducing iterations. VeraCrypt needs to protect some users from themselves.
A good rule to consider when talking about encryption is, if you think you are secure, you have overlooked something. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello.
First thank you for continuing this project after the strange Truecrypt end.
I have a SONY VAIO laptop using now "Veracrypt 1.04d" instead of "Truecrypt 7.1".
I works well except that after input my password, it takes one minute to start booting Windows7 64bits.
Can you please help me to improve this delay ?
Thanks in advance.
F Malaterre
Hi,
This delay is caused in part by the fact that we increased the iterations count to a level that gives us the best possible security while still being useable.
Another reason is that the encrypted partition doesn't contain any indication about the encryption algorithm for security reasons. So, in order to boot Windows, VeraCrypt tries all available encryption algorithms in sequential order (AES -> SERPENT -> TWOFISH -> TWOFISH+AES -> SERPENT+TWOFISH+AES -> AES+SERPENT -> AES+TWOFISH+SERPENT -> SERPENT+TWOFISH). Thus, if you choose an encryption algorithm that is in the middle if the list (for example AES+SERPENT), you will wait more time than if you choose AES only.
For that point, we are thinking about adding an entry in the boot menu to let the user select the correct encryption algorithm so that we can save time.
Last point : the code of VeraCrypt BIOS boot loader runs in a restricted environment with limited resources and legacy mode (16-bit), which make all cryptographic computation slower. Once Windows is started, we go back to normal more with no performance degradation.
We can do nothing about this. In the future, we plan to support UEFI boot which enables the use of more resources for booting.
As a summary, we can optimize only the case where an encryption algorithm other than AES is used by enabling the user to select the correct encryption algorithm directly instead of trying all combinations. If tests are OK, this could be included in the next release.
FYI... I chose AES, and just encrypted a 12 gig partition on the drive, NOT a system boot partition and it too takes noticeably longer to mount than with Truecrypt. BUT once mounted the files seem to process just as fast as Truecrypt's last version. I am going to start a second thread about some behaviors I have noticed.
-Sir.Roberte
Thanks for this feedback.
Yes, the mount of a volume under VeraCrypt is slower than TrueCrypt because of the enhanced security of key derivation as explained in my post. As you pointed out, once mounted, read/write operations have the same performance as for TrueCrypt.
Everyone commenting on the slow speed, or how much longer VeraCrypt takes to open a container should actually see this as a positive !!! The longer it takes the genuine user to open the container with the correct password the better, just imagine how much harder it will be for the attacker !
Users just don't seem yo understand the benefits of this, which is disappointing.
Anything that degrades the performance of a pc is not a "Positive"
hi
Hello,
I had use the true crypt software but after stop service we have try vera crypt both installation as same as per my observation. i have getting issue when i insert password while booting it will take 40 sec to accept the password any idea how to decrease time or any option for fast booting. please reply
Thanks in advance
Hi,
For those who prefer to have a fast boot, we are currently implementing a security level choice where the user can choose to have strong, medium or low security.
The low security mode will be the fastest and at the sametime it will be stronger than TrueCrypt (10000 instead of 1000).
We'll release a beta version that includes this feature soon, so stay tuned.
Has this vesrion been released yet??
No and we don't think that this feature is going to be included after all. We had some exchanges about it with different users and it appears that it will add confusion about the real security level of VeraCrypt and it will also be a big departure from the spirit of TrueCrypt were all created volumes are assured of having the same level of security.
Moreover, as I always repeat, this delay affects only the boot time and not the performance once Windows is loaded, so it is worth waiting if you have really sensitive data that need this level of security.
A more important feature is to rewrite the bootloader in order to evade the limitation of the current 16-bit mode that makes the performance of the boot so poor. Once we have a 32-bit bootloader, the boot time will dramatically decrease without a need for decreasing the security of the encryption.
"we don't think that this feature is going to be included after all"
AWESOME !!! :)
I am really pleased to read that ! VeraCrypt is 100% security, no compromise :D
L0ck
If the delay is too long on older systems and users have no alternative, one might argue they may not use it at all. While 'confusing the user' is one reason for omitting, it is certainly no more complex than remembering which keyfiles were used to protect a non-boot volume. If the choice of selecting hashing iteration levels at boot is added, adding a 4th paranoid level using 2x-5x more iterations than the high security level(and resulting in an even longer hashing delay) is equally attractive.
Hello, could you please implement this to give the user the option to boot faster. I have a relatively fast CPU 3700K OC 4.2Ghz, but authentication at boot up still takes up to 30 seconds. I have already spent days encrypting a few large volumes with veracrypt, and it will cost too much time to revert to truecrypt. Or at least please release a "sideline" version with this function.
Seriously, if 30 seconds is too much to ask then you have no need for this security product.
Your threat model is simply not significant enough.
I understand that for TrueCrypt users, booting using VeraCrypt would seem like an eternity but you can't have a fast boot and a good security level.
As I explained in different posts, reducing the key derivation complexity to make it as fast as in TrueCrypt is not the good answer. The objective of VeraCrypt is guarantee a minimal security level for the next 10 years and the key derivation complexity was chosen with that respect.
The real solution is to rewrite of the bootloader in order to switch to full 32-bit performance which will divide the boot time by a 2 or 3. This is part of the roadmap and it is the next objective of VeraCrypt.
I receive numerous request asking for the release of a version with faster boot (e.g. lower security) but I'm still not convinced if it is good on the long run.
Things may change in the future if I have or I received better ideas on how to implement such "security customization" without affecting VeraCrypt security targets.
I've noticed a major improvement in mount time with 1.0fBETA3; thanks.
Thank you Stephen for this feedback and for your support.
Happy new year, wish you all the best.
Ignore the detractors Mounir, aim for security only. People such as those above who need speed not security can use a less secure product, keep VeraCrypt for those who need real security.
Personally I think the full 32bit performance should perhaps be number 1 on your "to do" list :)
It will stop a lot of threads like this one.
Agreed. Ignore the detractors. You just never know who might be offering this type of advice/suggestion.
-EOM
Please implement fast boot, I don't see any problem at all. People beeing confused of this function are too "confused" to use a secure password. Nobody would be confused at all.
As long as people can choose to use a high iteration then there is no problem. And no, I don't come from the NSA, I come from planet usability and with Windows I have to reboot a lot of times and was so happy that after my SSD and Windows 8.1 I can boot up in less than 15 seconds and now this problem comes up...
Let the people be free in their choice, freedom is dangerous but when giving up freedom for security you will loose both in th eend (probably not the wisest quote to use in this context, but it sounds cool and makes sense in the political context).
Hey, you have to implement an option to use lower iteration, it can be still higher than TC but every user should be able to decide himself if he wants to get high bruteforce security or low bruteforce security, although the length of the password can completely eradicate the need of high iterations... so pleaaaaaaaase give us this feature!
At this point Veracrypt is unusable for my system partition which is really sad! Let the users decide if they want high iterations or not!
"although the length of the password can completely eradicate the need of high iterations"
This is not necessarily true, your use of the word "can" saved you from ridicule.
So why do you think it is wrong? When you have a 64 character password then there is no need for high iterations, cause bruteforcing even in realtime would take hundred of years and that includes progress in technology that we are able to foresee. It is more likely that AES 256 Bit can be defeated than the password...
So, I have nothing against high iterations but please, dear Mounir, implement the option of a lower iteration count like 10.000, that is still 10 times higher than the TC count! There are NO disadvantages of giving us this feature!
It is wrong because most users are not aware of what a good password is.
Length is not a guarantee of strength. Some unskilled users think quotes, poems and song lyrics are good long passwords, they would certainly meet your criteria for length.
However crackers already have very large dictionaries which contain these lines. Rules are used to manipulate leet characters and add dates etc.
So as you can see, there is actually a very serious disadvantage to reducing iterations. VeraCrypt needs to protect some users from themselves.
A good rule to consider when talking about encryption is, if you think you are secure, you have overlooked something. :)