Feb 28, 2015 at 9:00 AM
Edited Feb 28, 2015 at 10:20 AM
The biggest complain about VeraCrypt is the amount of time it takes to unlock a volume and the delay is due to the high number of iteration counts.
Going through posts and i have not seen any discussion about how these iteration numbers were obtained.
A 50,0000 iteration number seems like it was taken simply because its an easy number to write and remember but 655331 seem pretty detailed,why this particular number and not any other number? Why were these numbers chosen and not any other numbers? why 50,0000
and not 40,0000 or 70,0000 for example?
It will also be nice if there was a survey that how long it takes to unlock a VeraCrypt volume in people's computers and i will go first.
test was done on a 64 bit linux based computer using "Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz" CPU.
using zuluCrypt and cryptsetup,it takes about 8 seconds to unlock a normal volume,about 1.03 minutes to unlock a hidden volume and about 4.55 minutes to report a wrong password.
using VeraCrypt,it takes about 4 seconds to unlock a normal volume,42 seconds to unlock a hidden volume and about 1.25 minutes to report a wrong password.
A much larger time difference it takes zuluCrypt to report a wrong password is probably because it also attempts to unlock the volume as system volume and VeraCrypt does seem to do this automatically.
Feb 28, 2015 at 8:59 PM
Determining a secure number of iterations for key derivation function PBKDF2 is not something that can be done through simple formulas. Thus most of the values recommended by various organizations and standards evolve with time and they tend to be determined
As far as I'm concerned, I like including the notion of entropy in the determination of secure iterations count. A good approach that can be used as a base for such determination is what is described in Schneier paper (https://www.schneier.com/paper-low-entropy.pdf
and nicely summarized in the
By using a key derivation function which requires 2^s cryptographic operations to compute, the cost of performing a brute-force attack against passwords with t bits of entropy is raised from 2^t to 2^(s+t) operations.
In VeraCrypt, the chosen iterations numbers provide around 19 bits of entropy. Theoretically this is equivalent to 524288 but I choose 500000 to be more "friendly" (it is still 18.93 bits). On the other hand, the 655331 was chosen at the time both
for internal implementation reasons and also to compensate for the weakest security of RIPEMD-160 compared to the other modern hashes used.
In the next version, I'm planning to add a dynamic mode that will include the possibility for the user to specify a custom iterations count bigger than 500000 and smaller if the password is longer than 20 characters. Details of this are explained in the following
I like your proposal to have a survey for volume mounting time on various architectures. Actually, I implemented some optimizations lately on the key derivation implementation that resulted on 20% speed gain on 64-bit machines. I also published on Git a benchmark
batch file for Windows alongside test volumes:
On a Core-i7 2600K CPU @ 3.40 GHz running Windows 7 64-bit, the file bench.bat outputs the following:
SHA-512 (Normal) = 00:00:03,45
SHA-512 (Hidden) = 00:00:06,84
Whirlpool (Normal) = 00:00:06,78
Whirlpool (Hidden) = 00:00:13,49
SHA-256 (Normal) = 00:00:05,04
SHA-256 (Hidden) = 00:00:10,19
RIPEMD-160 (Normal) = 00:00:10,67
RIPEMD-160 (Hidden) = 00:00:21,36
Wrong Password (PRF Auto-detection)= 00:00:21,61
Times are in seconds.
On Linux, I still have to code a benchmark script so I can't give numbers here. In the case of wrong password with PRF auto-detection, Windows is always quicker than Linux because on Windows VeraCrypt implements a parallelization algorithm for PRF auto-detection
whereas on Linux it just check all available PRFs in a sequential way.
For your information, I have just published the Linux binaries of Beta version 1.0f-2-Beta which includes the speed optimizations. If you used version 1.0f-1 in your benchmark, you can use the 1.0f-2-Beta binaries to check if you also notice the 20% gain I
measured on my side.
You can grad these binaries on Sourceforge Nightly builds folder:
I redid my test using version "1.0f-BETA" and i didnt see any improvements.
I wrote a Qt/C++ program that does the benchmark and the output of the program is below.
It looks like veracrypt is faster than cryptsetup on all tests.
The repository where i host the benchmarking program together with test images is:
Source code,64 bit binaries and testing images are included.
[root@mtz benchmark]# ./cryptsetup_veracrypt.benchmark
testing sha512(normal) elapsed time: 7 seconds
testing sha512(hidden) elapsed time: 1.02 minutes
testing whirlpool(normal) elapsed time: 39 seconds
testing whirlpool(hidden) elapsed time: 1.55 minutes
testing sha256(normal) elapsed time: 49 seconds
testing sha256(hidden) elapsed time: 1.72 minutes
testing ripemd160(normal) elapsed time: 24 seconds
testing ripemdi60(hidden) elapsed time: 1.32 minutes
testing wrong password elapsed time: 2.70 minutes
testing sha512(normal) elapsed time: 3 seconds
testing sha512(hidden) elapsed time: 40 seconds
testing whirlpool(normal) elapsed time: 12 seconds
testing whirlpool(hidden) elapsed time: 49 seconds
testing sha256(normal) elapsed time: 18 seconds
testing sha256(hidden) elapsed time: 55 seconds
testing ripemd160(normal) elapsed time: 36 seconds
testing ripemdi60(hidden) elapsed time: 1.20 minutes
Mar 1, 2015 at 7:01 PM
I think you used an old version because the latest one is 1.0f-2-Beta...notice the "-2" after 1.0f.
Can you please try with the correct version?
Sorry for the big mess in the nightly builds directory...I'll remove all the old beta versions.
Thank you for the link to the benchmark script. Can I include a similar script in VeraCrypt repository? Of course, all credits will go to you.
Mar 1, 2015 at 7:56 PM
Edited Mar 1, 2015 at 10:30 PM
This is the output with "1.0f-2-Beta,released on february 28.2015".
There seems to be a consistent drop in delay in all tests.
I think it will be better if there was an option to suppress the GUI window that gives the warning.about delay time as
people create front ends to veracrypt CLI may not want it to pop up on them.
Yes,you can include the script and you can modify it as you please. let me know if can change anything to adopt it to your needs.
[root@mtz veracrypt_benchmark]# ./veracrypt.benchmark
testing sha512(normal) elapsed time: 2 seconds
testing sha512(hidden) elapsed time: 36 seconds
testing whirlpool(normal) elapsed time: 11 seconds
testing whirlpool(hidden) elapsed time: 45 seconds
testing sha256(normal) elapsed time: 16 seconds
testing sha256(hidden) elapsed time: 50 seconds
testing ripemd160(normal) elapsed time: 33 seconds
testing ripemdi60(hidden) elapsed time: 1.10 minutes
testing wrong password elapsed time: 1.22 minutes
Mar 1, 2015 at 9:02 PM
Thanks for the update. Your results are consistent with the expected speed gain.
You can suppress the GUI by using the documented switch --text. The only issue is that it prints several GTK warnings...