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

Too much slow

Topics: Technical Issues
Jun 26, 2014 at 11:15 AM
Unfortunately, Veracrypt is painfully slow mounting encrypted drives. In my 16 GB flash drive, it takes too long to mount the drive, while the explorer.exe freezes and the veracrypt process simply stops responding for at least 3 minutes, even in my i7 2840 core system.
If you intended to be a serious candidate to replace Truecypt, i think you must think seriouslly a form to improve program performance or most people will prefer continue using TC, despite the allegated risc security issues.
Coordinator
Jun 26, 2014 at 8:01 PM
As you may know, no information about the type of PRF used in key derivation is present in the volume header for security reasons. Thus, VeraCrypt (and TrueCrypt) tries all available PRF functions in a sequential order till it finds the correct one (RIPEMD160 -> SHA2 -> Whirlpool)

TrueCrypt is using very low iterations number which makes trying all functions fast for the end user. On the other hand, VeraCrypt uses high iterations count that makes this process painfully slow, especially if Whirlpool is used (Maybe it's your case).

Of course, we have been aware of this since the birth of VeraCrypt and we have two ideas on how to improve the situation :
  • Phase out RIPEMD160 : Once SHA2 is implemented for Boot encryption, RIPEMD160 will be put in legacy mode reducing the number of available derivation functions. Of course, in the future, we will add hash algorithms (like SHA-3), so it is not viable on the long run. Also, this will not apply to existing volumes.
  • Add a combo box on the volume opening dialog in order to let the user choose between automatic PRF search (current way) or manual PRF selection. This will dramatically speed up thing. Some would say that this is would give information to an attacker capturing your screen (tempest like attack) but even in this case, the number of iteration and the length of the password would still protect again brute-force attack. At least, the user would have a choice.
The second idea is the most efficient but we need to have feedback from the community about it. Of course, it needs some code rework in order to be implemented as it touches the device driver code.

Anyway, thank you for your feedback about this. And since this is an open source project, all ideas and/or patches are welcomed in order to improve VeraCrypt.
Sep 13, 2014 at 11:48 AM
Edited Sep 13, 2014 at 12:42 PM
What about multi-threading? Why don't you try the PRFs in parallel?

btw: If the knowledge of the PRF is a real advantage for an attacker, the PRF should not be used. If it is secure and it takes thounds of years to brute-force it, then the factor of ~ 3 gained by the knowledge about which PRF was used is practical no advantage.
Remember Kerckhoffs's principle ;)
Coordinator
Sep 14, 2014 at 7:37 AM
Hi,

Under Windows, VeraCrypt already uses multi-threading for PRF checking when mounting an encrypted volume. Inside the kernel driver, a pool of encryption threads is created upon start-up and this pool is used to perform encryption/decryption operations in parallel (EncryptionThreadPool.c, line 213 : function EncryptionThreadPoolStart).

The size of this threads pool is equal to the number of logical CPUs available on the system because for such extensive operations a dedicated CPU is needed for each thread. Thus, if the system has only on CPU (for example under a VM), then no multi-threading is used.

Moreover, this threads pool is shared between all encryption/decryption operations done by VeraCrypt on the system. So, if your Windows is running on an encrypted system partition, this implies that parts of the threads pool is already used by the encryption/decryption operations needed by the OS read/write operations and thus when you mount an encrypted volume, the PRF testing can use only a the remaining slots of the threads pool. In this case, and depending of the total number of logical CPU available and the current executing processes, it is possible that no free slots are available in the threads pool and thus the PRF testing will not benefit from multi-threading.

Of course, in many other cases, the PRF testing will be accelerated thanks to the use of this pool of threads and actually this is what's happening for most of users (Volumes.c, line 247 : function ReadVolumeHeader)

In my previous I didn't mention this because of the complexity of the different cases I mentioned above and also because of the fact that in the bootloader mode (when you have to enter a password to start the encrypted system partition), we can't implement a multi-threaded approach because of the restricted environment under which the bootloader code is running (BIOS mode, limited code size and available memory).

Concerning your last comment about the PRF knowledge, I think you are missing a key point : a VeraCrypt encrypted volume content should not be distinguishable from random and as such should not be identifiable as a VeraCrypt volume. This is the most important security principle behind VeraCrypt as it was behind TrueCrypt, it is called Plausible Deniability.
In order to fulfill this security requirement, an encrypted volume can't have a clear header part where the PRF can be stored because ALL the content must encrypted to look random. Thus, there is no way to know which PRF was used for this volume and the only solution is to try them all.

I strongly advice everyone to read the user guide that is installed by the VeraCrypt installer. It comes from the original TrueCrypt distribution but most of the technical aspects described there still apply to VeraCrypt. Inside it, there is a complete chapter concerning Plausible Deniability, along with other paragraphs talking about PARALLELIZATION and PIPELINING.

I would like to thank you about your question that gave me the opportunity to explain these deep technical aspects. We are encouraging everyone to study VeraCrypt code and architecture, and to challenge the technical choices that were made in its implementation. This is very important in order to enhance VeraCrypt and keep it inline with the requirements of today's challenging world.
Sep 20, 2014 at 8:35 AM
Edited Sep 20, 2014 at 8:41 AM
You're right, I missed that point.

What about using a random value (0...255) for a byte which is equal to the PRF_ID modulo PRF_count. This "looks" random, but the information can be derived?!
Coordinator
Sep 20, 2014 at 2:23 PM
Hi,

"security through obscurity" is not a good solution and in the case of an open source solution it is not adapted at all since everybody can look at the implementation.

Your suggestion of having a random byte that describes the PRF in a hidden way implies that the user must manually make the association between the random byte and the PRF since we can't implement this in the source code (see my first sentence). This also implies that in the GUI or the boot menu, the user will choose which PRF to use once presented with the value of the random byte.

Since the user needs to make a choice, this mechanism is logically equivalent to let the user choose the PRF to use without encoding any information in the volume header.

Actually, this is what I described in my first answer in this post when I talked about adding a PRF combo box.

As a conclusion, in order to safe guard the Plausible Deniability principle and the same time optimize the volume opening speed, the only solution is to give the user the possibility to specify which PRF was used to encrypt the volume. And as I said in my first post, such a solution needs heavy work in the Device driver code but we hope we can implement for the next version of VeraCrypt.
Sep 20, 2014 at 4:01 PM
Edited Sep 20, 2014 at 4:13 PM
In my definition "security through obscurity" means to protect by not documenting how the PRF is stored - this is not what I suggested.

The only information an attacker gains is "if this WAS a VC volume, the PRF would be x" - regardless of the actual value of the byte, the chunk of data might be a VC volume or not. As any value is possible I don't see how this would negatively impact plausible deniability?!
Oct 23, 2014 at 11:03 AM
Edited Oct 23, 2014 at 11:03 AM
I'm currently using TrueCrypt, but am orientating to see whether to switch to VeraCrypt.

Just to understand how this works:

1.
If I choose RIPEMD160 it will be the fastest to mount because that's what VC tries first? But after the next version(?) SHA2 will be tried first?
So, if I create a new container, for now I should choose RIPEMD160, but later on I should switch to SHA2?

2.
Can I convert a container from RIPEMD160 to SHA2 when this new version comes?

3.
Unrelated, are my current TrueCrypt containers compatible with VeraCrypt? If not, is there a conversion tool?

Thanks in advance for informing.
Coordinator
Oct 23, 2014 at 8:49 PM
  1. As explained previously, current version of VeraCrypt (1.0e) mount RIPEMD160 volumes faster that the other algorithms because it's tried first. In the next version, SHA-512 will be tried first and thus it will be faster to mount volume encrypted using SHA-512. You can always switch between RIPEMD160, SHA-512 and Whirlpool at any moment using the menu "Set Header Key Derivation Algorithm": a dialog will show up and you can choose the PRF algorithm you want. So, if mount speed is important for you, you can choose RIPEMD160 for now and in the next version, you can update your container to use SHA-512 instead.
    Image
  2. Yes, you can do the conversion as explained above.
  3. VeraCrypt is not compatible with TrueCrypt containers. There have been many posts asking for compatibility and we understand the need for those who have huge amount of encrypted data. We are planning to implement a conversion tool and hopefully it will make it to the next version if everything goes as planned. The only point is that we can support only containers created with versions 7.x (version 7.0 was released on July 19th 2010).
Oct 23, 2014 at 9:49 PM
Ok, that is great. I have multiple v7.1a containers with terabytes of data. I can't easily recreate them, so support or automatic conversion would be great.

I'll wait for that version then. Thanks for informing.
Jan 6, 2015 at 6:46 AM
First of all many thanks to Mounir for creating and maintaining VeraCrypt project.

Recently, I have tried VeraCrypt 1.0f-1 expecting to replace TrueCrypt 7.1a.
Either I do something wrong or VeraCrypt has absolutely unacceptable "speed" of encryption and decryption...actually VeraCrypt 1.0f-1 is 20 times (!!!) slower than TrueCrypt 7.1a on my system (Intel Xeon X5675 3.07GHz, 16GB DDR3-1333 ECC, Windows 8.1 Pro x64).

Just created a 30 Mb Standard VeraCrypt file container (AES & SHA512) and Hidden TrueCrypt file container (hidden: Serpent-Twoish-AES & Whirlpool in normal: AES-Towfish-Serpent & SHA512) with the same password. It took several times faster to create a hidden TrueCrypt container with triple encryption algorithms and Whirlpool than a standard VeraCrypt container with AES and SHA-512.
Furthermore, it took 20 seconds to decrypt this standard VeraCrypt container in VeraCrypt 1.0f-1 comparably with 1 second for hidden triple encrypted TrueCrypt container opened/decrypted in VeraCrypt 1.0f-1 with TrueCrypt mode enabled (TrueCrypt 7.1a opens/decrypts it's containers and huge Gb disks for less than 1 second).

Despite the fact that VeraCrypt probably safer than TrueCrypt, the decryption/encryption speed makes VeraCrypt simply useless - nobody wants to wait for minutes in completely frozen system just to mount a standard AES encrypted file/disk with few Gbs. It reminds me sophisticated antivirus with triple engines which slow down the system worse than some viruses and you have to think twice what is better: to take heavy medication or to get sick.
Hopefully the issue will be solved in close future.
So far, I keep using "unsafe" but turbo fast TrueCrypt.

Regardless, thank you for your work again.
Coordinator
Jan 6, 2015 at 8:33 AM
Hi fog,

Thank you for your feedback but I would like to clarify some points because your choice of words can be confusing for some users and it can add to misconceptions that exist about VeraCrypt.

VeraCrypt is not slower than TrueCrypt during the usage of a mounted container. VeraCrypt doesn't slow your PC compared to TrueCrypt. VeraCrypt decryption/encryption speed of data is the same as TrueCrypt.

In your last paragraph, you are talking about encryption/decryption speed and in the same sentence you are talking about mounting performance. This can give the false impression that VeraCrypt is slow at decryption/encrypting your data which is not true.

It is unfair and unjust to compare the slowness mounting speed with an Antivirus slowdown of a system: VeraCrypt is only slow to mount a volume (which can take up to a minute) but after that everything is as quick as in TrueCrypt. An Antivirus will slowdown your system all the time.

During the creation of encrypted volumes, VeraCrypt is slower than TrueCrypt for the same reasons it is slow at mounting them. And as for mounting, creating a encrypted volume is a one time operation and its slowness doesn't affect the speed of use the volume.

I would like people who review VeraCrypt to be as clear as possible and more honest about their comparison between VeraCrypt and TrueCrypt. Telling users that VeraCrypt slows their machine is false and it doesn't help any one. It is like telling people that formatting a 1TB hard drive slows your machine: the performance impact of the formatting happens only during the creation of the disk but afterwards it is a normal disk.

As usual, I repeat the same simple facts:
  • VeraCrypt takes more time to load encrypted volumes. Once the volumes are mounted, it has the same Read/Write speed as TrueCrypt.
  • VeraCrypt takes more time to create encrypted volumes.
I believe these facts gives a more honest description VeraCrypt.
Jan 6, 2015 at 1:20 PM
It never ceases to amaze me that people take the time to write posts complaining about the time it takes to hash a password rather than actually spend that time reading why VeraCrypt takes a little longer compared to other less secure products.

If these same users do not require the additional security VeraCrypt offers then they should use a less secure product, like TrueCrypt or ChiperShed.

Mounir, I suggest you write one more complete and detailed explanation of this feature on you site. Explaining exactly why VeraCrypt is slower to authenticate a password and why this is so VERY IMPORTANT FOR SECURITY.

From then on, don't waste your valuable time explaining again and again to these people. Simply post a link to the new page.
Jan 6, 2015 at 6:11 PM
idrassi wrote:
your choice of words can be confusing for some users and it can add to misconceptions that exist about VeraCrypt.
VeraCrypt is not slower than TrueCrypt during the usage of a mounted container. VeraCrypt doesn't slow your PC compared to TrueCrypt. VeraCrypt decryption/encryption speed of data is the same as TrueCrypt.

In your last paragraph, you are talking about encryption/decryption speed and in the same sentence you are talking about mounting performance. This can give the false impression that VeraCrypt is slow at decryption/encrypting your data which is not true.
Hi Mounir,

Thank you for your prompt response.

Sorry if my words confused someone. For sure, I did not intend to add any misconceptions about VeraCrypt.
As it was mentioned above "VeraCrypt 1.0f-1 is 20 times slower than TrueCrypt 7.1a on MY SYSTEM (Intel Xeon X5675 3.07GHz, 16GB DDR3-1333 ECC, Windows 8.1 Pro x64)". Good for you guys if "VeraCrypt doesn't slow your PC compared to TrueCrypt" but I have completely opposite result. That is not my opinion or impression...it is just a fact
When I started to research this matter I found other guys experiencing the same issue (e.g. topic starter and other posts/videos in Internet).
I share my experience just to improve VeraCrypt (or my system?) but not to tarnish your reputation. Currently, there are simply no other decent alternatives for dead TrueCrypt to promote them here.
VeraCrypt is only slow to mount a volume (which can take up to a minute) but after that everything is as quick as in TrueCrypt.
"up to a minute" is unbearable for normal working usage....at least for me.
I would like people who review VeraCrypt to be as clear as possible and more honest about their comparison between VeraCrypt and TrueCrypt. Telling users that VeraCrypt slows their machine is false and it doesn't help any one.
No doubt, I also do like people who like me, ;) however, prefer to receive a frank criticism than listening to lickspittles cuz this helps to improve myself.


Well...how to explain the following video - another "false impression" or "dishonest description"?
https://www.youtube.com/watch?v=fU25BDHst4Y
Coordinator
Jan 6, 2015 at 7:29 PM
Hi fog,

Your video doesn't contradict my statement: it shows that VeraCrypt is slow at mounting volume. But afterwards, is it slow? No at all.

I respect that you want to insist on the performance of the mounting operation, but as L0ck explained, it is amazing to focus on the hashing of the password instead of the use of the data after the password is validated.

The confusion comes from the fact that people will think that VeraCrypt is slow for using while it is only slow for validating your password.

So, I would like in the future the people who want to talk about this subject to clearly states that "VeraCrypt is slow at validating the volume password". This is much clearer that VeraCrypt is slow.
Jan 6, 2015 at 8:03 PM
Edited Jan 6, 2015 at 8:06 PM
At the risk of contradicting the master... :)
"VeraCrypt is slow at validating the volume password"
VeraCrypt is not slow, it is actually doing a lot in the background, very quickly !

The problem is VeraCrypt "appears" slow, when in actual fact the job is a much greater one than for TrueCrypt or ChiperShed for example.

I personally enjoy this delay, it gives me a lot of confidence, but I took the time to find out what is going on and why.
Jan 6, 2015 at 11:34 PM
Edited Jan 7, 2015 at 12:25 AM
The VeraCrypt user display is a big problem - it actually encourages the user to think that VeraCrypt is too slow!! Telling the user that the program will take a long time and may become unresponsive is very, VERY bad form.

During lengthy installations many products entertain the user with tales of exactly what is happening while the user waits, along with numeric indicators and graphic displays of progress (% complete, etc.). With enough progress reporting and enough entertainment along the way (see Firefox's exemplary installation process which includes a very entertaining and informative haiku along with lots of great progress reporting and eye candy), the wait will become enjoyable!

VeraCrypt should look very closely at how it can better entertain and inform the user during both the volume creation process and the volume mounting process.
Jan 7, 2015 at 1:06 AM
I hope everyone will support the idea I described above by going over to the ISSUES tab and upvoting the "Inform & Entertain VC User During Wait Times" issue. Thanks! :)
Jan 7, 2015 at 5:32 AM
idrassi wrote:
The confusion comes from the fact that people will think that VeraCrypt is slow for using while it is only slow for validating your password.
So, I would like in the future the people who want to talk about this subject to clearly states that "VeraCrypt is slow at validating the volume password". This is much clearer that VeraCrypt is slow.
Agree. However, while I see the reason of long time validating/mounting it is simply unacceptable for me personally (due to frequent mounting/dismounting encrypted volumes), especially during meditation looking at my frozen system with 6 physical core (12 virtual) 3.07 GHz server processor and 16 Gb memory.
I prefer the classic isosceles Infosec triangle:
Image
The current VeraCrypt conception tends to another shape with longer left side (Confidentiality).

Fortunately, in the last version (1.0f) you kindly provided an option to select algorithm manually which greatly (twice on my system) increases validating/mounting speed.

Thanks a lot again for maintaining VeraCrypt project.


mtpagkatipunan wrote:
We need not to tell the user "VeraCrypt is slow and appears unresponsive..."-- just the above message and the actual progress bar would suffice. Instead of a progress bar, a progress indicator could also be a countdown timer which can also "entertain" users as noted by commenter8 above. Perhaps the display could be like "5 seconds to open", "4..."3..."... Pressing the "ESC" key would be also a good feature to cancel the process, as sometimes, we would just want to cancel anyway.
Though this interface will not speed up the entire process, it should save some nerves....but melancholics will be disappointed losing their joy from this uncertain frozen delay. ;)
Anyway, it is a good idea.


commenter8 wrote:
I hope everyone will support the idea I described above by going over to the ISSUES tab and upvoting the "Inform & Entertain VC User During Wait Times" issue.
Any link? I would immediately vote.
Thanks.
Jan 7, 2015 at 8:03 AM
Edited Jan 7, 2015 at 8:04 AM
Link to the VeraCrypt issue "Inform & Entertain VC User During Wait Times" is here:

http://veracrypt.codeplex.com/workitem/59

Thanks for your upvoting support! :)
Jan 7, 2015 at 1:16 PM
commenter8 wrote:
Link to the VeraCrypt issue "Inform & Entertain VC User During Wait Times" is here:
http://veracrypt.codeplex.com/workitem/59
Thanks.
Voted.
Jan 7, 2015 at 9:27 PM
Hi,

Unfortunately I'm not so familiar with PRF, so please accept my apology for asking stupid questions..
"TrueCrypt is using very low iterations number which makes trying all functions fast for the end user. On the other hand, VeraCrypt uses high iterations count that makes this process painfully slow"

Why does it needed to do so many iterations? Because there is so many possiblilties for they key type, or to have a really random key?

Would it be possible to use a low iteration number to find the correct type, and once you have that use a high iteration number against that type?

Thanks
Jan 7, 2015 at 10:01 PM
Edited Jan 7, 2015 at 10:08 PM
Not possible because finding the correct type can only happen after the many iterations have been done. This creates very strong security against attackers. Doing as you suggest would create a shortcut that attackers could then exploit to potentially succeed in making an unauthorized entry into the secure container. TrueCrypt's system is considered to be too weak to provide sufficient security, and so VeraCrypt is designed to be much stronger.
Jan 9, 2015 at 5:09 PM
Is there a way to save the preferred PKCS? I have an encrypted profile for Thunderbird which I mount and dismount quite often and I would like to always use SHA-512 for improve speed.
Jan 9, 2015 at 5:26 PM
The uncertainty of which method to use is a critical part of the strategy for making an attack on VeraCrypt as difficult as possible. If such information were to be stored, it would have to be stored under a level of encryption that is at least as strong as the encryption on the VeraCrypt container itself, so you wouldn't see any kind of speed improvement.
Jan 9, 2015 at 5:30 PM
This is a requested feature from referencing thread:

http://sourceforge.net/p/veracrypt/discussion/features/thread/5cf604bf/

I went ahead and made a formal request for this feature:

https://veracrypt.codeplex.com/workitem/61
Jan 9, 2015 at 5:31 PM
LOL

I have just deleted my reply, commenter8 has read my mind.... again ! LOL
Jan 29, 2015 at 6:37 AM
I was a bit worried about the 'wait a minute... or 3! to mount' issue.

I created a 1.5TB container with a very long password and SHA-512. I have an i5-3570 quad core, which is fast, but by no means top of the line. To my great surprise it mounts within a couple of seconds!

My question is, does VeraCrypt try to verify the header first with SHA512? Why is it so fast when others have to wait several minutes, did you lower the iteration count?
Coordinator
Jan 29, 2015 at 11:34 AM
Of course I didn't lower iterations, otherwise it won't work with previously created volumes.

If you choose PRF automatic detection in the password dialog (this is the default) then SHA-512 is tested first and the mount time will be exactly the key derivation time.

Even of you use Whirlpool or SHA-256, the mount time should be less than 20 seconds.

Concerning the report of several minutes waiting time in VeraCrypt they are often related to the boot time and not the mount of volumes. The others who report this for volume mounting are using rather slow and low end CPU and sometimes their machines are not working properly.
There are also some false reports (minority)...these are just trying to give a bad image of VeraCrypt for some obscure reason.

Anyway, thank you for giving your feedback as it helps showing that, apart from the boot, VeraCrypt mounting speed is not as bad as some say when using modern hardware.
Feb 6, 2015 at 3:43 PM
Hello all, and thank you idrassi for VeraCrypt.

I am writing to hopefully benefit new users who want to optimize start up speeds with the current (1.0f) version of VeraCrypt.

I am running a 2 core 4 thread i7 laptop with 8gb ram. I am using an ssd as a system disk, and have a separate data disk. I am encrypting both disks with AES as the i7 has hardware AES assist. Previously I had been using TrueCrypt, then Bitlocker, until I found VeraCrypt. I am running Windows 8.1.

On my first attempt to set up VeraCrypt for the system drive, I chose the default prf of sha-256. My time from entering the password to continuing boot was 90 sec. I then attempted to change the prf from the VeraCrypt GUI to sha-512, but this had marginal effect on the boot time. I then decrypted the ssd, and re-encrypted using RIPEMD-160. This brought the time from password entry to continuing boot to 35 sec, which I consider acceptable. SHA-512 is not yet available for the system disk apparently.

For mounting the data drive, using the prf of sha-512 gave me manual mount times of about 20 sec on automatic detection, and 10 sec when specifying the prf manually. I find setting the drive as a "system favorite" produces a much more stable and quick overall boot than setting the drive as a simple "favorite", which induces disconcerting hangs and unresponsiveness in my desktop for a few minutes. Mounting the data drive manually after sign in is quickest, but I find setting the data drive as a system favorite is acceptably fast and convenient.

I hope this helps someone.
Feb 7, 2015 at 3:22 AM
SHBouwhuis wrote:
I was a bit worried about the 'wait a minute... or 3! to mount' issue.

I created a 1.5TB container with a very long password and SHA-512. I have an i5-3570 quad core, which is fast, but by no means top of the line. To my great surprise it mounts within a couple of seconds!
"couple of seconds" with 1.5TB encrypted container???
Could you please provide a video proof?
Please make a video in the same format like it has been done previously here: https://www.youtube.com/watch?v=fU25BDHst4Y
(he-he... who has already clicked on "dislike" there? ;) )

Recently, I have upgraded (double improved) my system expecting to increase decrypting/encrypting process of VeraCrypt:
Two Intel Xeon X5675 processors 2x3.07Ghz (2x6 physical cores + 2x12 virtual cores)
32 Gb (2x16 GB) KINGSTON-ValueRAM KVR13LR9D4/16HA, DDR3L-1333, ECC, Registered

Result? Almost the same speed - unbearably slow for me.
I've got 30 seconds to decrypt hidden pretty small container (115 Mb, Twofish->Serpent, SHA-512, Autodetection) and 10 seconds for the same container but with SHA-512 manually selected.
It seems, the speed of decryption/encryption does not depend on system resources too much.
Feb 7, 2015 at 12:00 PM
Edited Feb 9, 2015 at 9:14 AM
Here is a test where I mount and dismount a 1.5TB (1.500.000.000.000 bytes) a couple of times in a row.
It seems it averages at around 12.5 seconds. Do note that I was working on my system and that I have set VeraCrypt to low priority (with Process Lasso).

Image

And here is the same container, but now I'm specifying it should use SHA512.
As you can see, the mount time is 4 seconds.

Image


@idrassi
Why is there such a large difference in speed? I thought you said SHA512 was chosen by default?
Feb 22, 2015 at 6:51 AM
Edited Feb 22, 2015 at 6:55 AM
One thing that's kind of odd is. My drives are taking much longer to mount under Linux then windows. Not sure why that is?
Maybe something to do with the different file system header locations? I'm running Debian 7.8 Gnome EXT4. Both computers are built with the identical memory modules, CPU and amount of ram. The difference in mount times is double, Linux taking much longer.
Coordinator
Feb 22, 2015 at 12:10 PM
@SHBouwhuis
The behavior of automatic detection depends on the number of CPU cores available on the system.
  • If 1 core, then we test all the PRFs sequentially starting with SHA-512
  • if 2 or more cores, a parallelization algorithm is implemented that spreads PRFs testing across all cores and waits for the first one that succeeds which theoretically should be equivalent to selecting the correct PRF especially for SHA-512.
It appears though that the parallelization algorithm is flawed and that the overhead generated by using extra thread on each CPU core is much bigger than the computation itself.
This algorithm was inherited from TrueCrypt and it was not changed in VeraCrypt. I'll look into it in details and see how I can fix it.

@movingkey
I think you didn't measure only the performance of the mount but you also took into account the GUI overhead (displaying of the wait dialog for example).
In order to have a correct measurement of the mount operation without taking into account the overhead of the GUI (which depends on your window manager and any special theme you may be using), you have to use a command line like this one: veracrypt --text --slot=1 --hash=SHA-512 -p test --non-interactive test.hc

This command line suppose that you are mounting a container file named test.hc with a password "test" and using the PRF SHA-512. The volume will be mounted at slot number 1. No GUI will ever be displayed.
I did a measurement on my machine using the Linux builtin time utility and I have a mount time equivalent to the one using Windows . Here is the command I used for the measurement: sudo time -v veracrypt --text --slot=1 --hash=SHA-512 -p test --non-interactive test.hc
And its output was (minus the usual GTK asserts):
    Command being timed: "veracrypt --text --slot=1 --hash=SHA-512 -p test --non-interactive test.hc"
    User time (seconds): 0.01
    System time (seconds): 0.00
    Percent of CPU this job got: 0%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:04.63
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 40496
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 3571
    Voluntary context switches: 4
    Involuntary context switches: 243
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0
As you can see, it took 4.63 seconds to mount the volume on this Linux Ubuntu 64-bit. On the same machine, it takes 4.29 seconds using Windows 7 64-bit.

The command line used on Windows to perform the mount is: "c:\Program Files\VeraCrypt\veracrypt.exe" /volume test.hc /hash sha512 /l Z /password test /q /silent
In order to compute the time taken by the operation on Windows, you can use the method described here: http://stackoverflow.com/a/9935540/707093

I'm sure if you perform the measurement like I described, you'll get the same results.
Feb 22, 2015 at 2:51 PM
Tests performed on:
  • Windows 7 Professional Edition 64-bit
  • Quad Core I7 Intel Processors running at 2.6 GHz, 6MB L3 Cache.
  • Provided hash type in mount command instead of Autodetection.
  • VeraCrypt 1.0f-2-Beta version dated 2015-2-21
Using the link provided by Mounir for computing the time duration on Windows, here are my duration results for mounting file containers with each hash.

SHA-512 Mount Time.. : 0:00:03,91
SHA-256 Mount Time.. : 0:00:05,27
Whirlpool Mount Time : 0:00:13,37

I was expecting SHA-256 to be nearly the same time as SHA-512 and I expected Whirlpool to about the same time as SHA-XXX by a couple of seconds.

I am not saying there is anything wrong. I was surprised at the results due to the times varied more than I expected.
Coordinator
Feb 22, 2015 at 5:57 PM
@SHBouwhuis

I found the explanation why on multi-core processors the auto-detection takes more time for SHA-512: the parallelization algorithm correctly launches PRF calculations on all cores and he correctly picks up the SHA-512 thread result but the end of this algorithms we wait for the completion of all other threads in order to release allocated memory used by these threads.
    if ((selected_pkcs5_prf == 0) && (encryptionThreadCount > 1))
    {
        TC_WAIT_EVENT (noOutstandingWorkItemEvent);

        burn (keyDerivationWorkItems, sizeof (KeyDerivationWorkItem) * pkcs5PrfCount);
        TCfree (keyDerivationWorkItems);

#ifndef DEVICE_DRIVER
        CloseHandle (keyDerivationCompletedEvent);
        CloseHandle (noOutstandingWorkItemEvent);
#endif
    }

    return status;
}
So this means that the time taken by auto-detection will equal to the time taken by the slowest PRF. In practice, RIPEMD-160 is the slowest PRF so:
Time (auto-detection) = Time (RIPEMD-160)

As I said above, this is correct only for multi-core CPU (cores >= 2 which gives 4 thread using Hyper-Threading and we have 4 PRFs).

@Enigma2Illusion

I think you missed that in key derivation we don't use a simple hash but HMAC and since the digest size of SHA-256 is half of the one of SHA-512, HMAC-SHA-256 will need more hashes compared to HMAC-SHA-512 meaning it will take more time provided that SHA-256 takes almost the same time as SHA-512 (true on 64-bit machine but not on 32-bit machines).

Concerning Whirlpool, the implementation used by VeraCrypt (and TrueCrypt) is not optimized at all. I have to look for public domain optimized implementations to replace it.
Feb 23, 2015 at 4:33 AM
Edited Feb 23, 2015 at 4:44 AM
@idrassi
I understand what you're saying about using a command line to get an accurate test.

On a side note though: I would have thought Debian Linux would have substantially less overhead than windows 7. I do keep Win7 trimmed down, but it's only been a week since I installed Linux on another identical machine specs wise, and I have not installed any user programs on it. Note: Today however, the mount times were about the same as windows. So the only explanation I have is that maybe there was a system-service running on Linux at the same time I was mounting my drives.