Is a VeraCrypt partition slower?

My tests with a USB 3.1 Gen 2 Type C hard disk (able to write at 10Gib/s, aka a little more than 1GiB/s) is:

• Encrypted with TrueCrypt, veraCrypt, DiskCryptor or any other will make read and write to be much more slower, the best i got is arrond 100MiB/s (one tenth of non encrypted), so encryption makes it to be ten times slower.
• Copying a huge big large file (more than 600GiB file) on non encrypted fly, took a little less than 10 minutes), copying a huge amount of really very small files (with write cache on) makes same speed, please note that write such huge amount of really very small files without write cache tooks forever, aka speed goes down to a 1KiB/s (yes kilobyte), all theese tests without encryption.
• With VeraCrypt encryption, speed can not be 1GiB/s, and goes down to arround 100MiB/s, CPU is not enought fast, among it has 64 cores (i will explain it later how to improve it)... but, copying small files makes speed goes down to near 1KiB/s with write cache on... it is VeraCrypt fault... seems that it is not allowing caching the NTFS that is seen by windows, and Windows only can cache writes done to the HDD itself.

Oh, yes i had been very afortunated i could had (for some days only) a mainboard with 4 sockets and 4 microprocessors with 16 cores each, so a total of 64 cores... and RAM, wow! it was 32GiB of ram in 4 sections, each one near to each processor socket with 4 banks each and a 2GiB ram on each bank 4Sections*4Banks/section*2GiB/Bank=32GiB... the fastest PC i had ever touch.

In other words:

• Windows have write cache enabled (for the USB device), if not encrypted that cache improves a lot the small files writes.
• VeraCrypt seems to not allow windows to cache writes to the NTFS, because there is no way to Enable/Disable such cache, and small files writes is very, very slow.

I had tested with other Encryption software (very expensive) that emulates a whole SAS controller (yes Serial SCSI) and also emulates a whole HDD connected to it... so on windows you can enable and disable its write cache... with that software writting small files is as fast as writting a big file (if such write cache is enabled on windows).

I am talking about windows write cache, so i will explain how to enable/disable it for people that do not know how:

1. Open explorer and go to where you can see root folder of partitions mounted, C:, D:, etc.
2. Select any of thoose, right click and go to properties.
3. Go to Hardware and select the device on the list (here is the problem with VeraCrypt, it does not create a virtual controller).
4. Clik on Properties button.
5. On the General tab click on the button to change the configuration.
6. Now go to tab for directives.
7. There you can select to fast extract (write cache off) or to better performance (write cache on).

Remember if write cache is on, do not unplug without windows informing you can safely eject it... after asking for safe remove.

Well, that cache affects only to write operations done on the device, since the device is the physical one, it means for encrypted data written to the HDD, not for un-encrypted data written to the NTFS estructure.

So what happens? Windows writes to the NTFS estructure without write cache, then VeraCrypt do the encryption (yes pipelined) and send the encrypted data to the HDD, then Windows see the device has write cache on so waits a little to write the data... but modifing the NTFS estructure is done without cache... so in practice windows is asking VeraCrypt for encrypting the same structure a lot of times (when small files are written) in a short period of time... so VeraCrypt must encrypt a lot of times something that will be putted on the exact same cluster of the disk.

That causes a huge, very huge, slow down if compared with non-encrypted.

To whom belongs the fault? In part to Windows NTFS that do not cache estructure changes, in part to VeraCrypt for not emulating a device.

Such way of working of VeraCrypt (comes from TruCrypt, etc) causes another rare things, like SmartDefrag not able to see and defragment files on it (Piriform Deflagger can, so can be a bad algorithm on SmartDrefrag)... also BootIce see them as IFS: and not as HD#: or RM#:... some parttition manage apps are not even able to see it, etc.

Another side effect (for Linux people): In practice you can not format as Ext4 a VeraCrypt partition if you try on windows... at least all partition tools i tried that allow to create (i mean format) Ext4 partitions do not see VeraCrypt device (it is very normal as VeraCrypt does not emulate a device).

Among all this... for some BackUps (on Windows) i still use VeraCrypt and NTFS with compression enabled... and i do not enable physical device write cache (has no sence), why i want to cache writes of encrypted data... i want to cache NTFS modifications, not the data sent to the HDD... VeraCrypt uses a good write cache for such, so why double cache... the horrible part is Windows do not cache NTFS changes on RAM, only cache "Clusters" sent to disk.

And if you think putting veraCrypt encrypt engine on a more lower layer (nearest to HDD physical write) would gain something... wrong! the problem is this:

1. One small file write to NTFS is asked
2. Seach for empty entry on Dir occurs (in RAM)
3. Write the new entry on Dir occurs (in RAM)
4. Windows check device write cache (VeraCrypt does not emulate a device, so can not be consulted, so interpreted as there is no write cache on)
5. Since windows think (non-encrypted part) has no write cache, sends DIR clusters to HDD
6. VeraCrypt intercepts that and do the encryption (this is unnecesary if same clusters will be re-written in a near future, as occurs when writting a lot of small files on the same folder)
7. VeraCrypt send encrypted data to the HDD
8. Windows check if device (this time it is the real one, so can be consulted) and see write cache is on (or off)
9. If was on, it do not write "encrypted" cluster to physical disk, it waits a little
10. Got to step 1 for next file

That is the problem... steps 5 and next steps... they would not be done if NTFS has write cache... but VeraCrypt does not present the option for caching at that level.. to do that it would need to emulate a whole device.

So what happens is that the clusters where the folder list of files is stored is sent to VeraCrypt a lot of times, one per file; instead of sent if only once after all files are set in the directory.

Said with little words: the problem is encrypting a lot of times the same folder listing... think it as encrypting the whole text after you write each letter versus encrypting the whole text after you finish writting it... that makes things to go really slow (when a lot of changes are maded in a short period of time to the same folder, like adding a lot of small files).

Not to mention, this problem also affects file deletion... put more than ten thousand files on a folder on a not encrypted disk (with write cache on), delete them tooks less than a second (if write cache is off it tooks more than one hour), now do the same but having the partition encrypted and write cache on (yes, activated), delete so much files causes ten thousand times to encrypt the folder list of files, it also takes a lot on that same disk (quite near as if not encrypted without write cache).

So, to talk in general: Encryption can make operations go much more slower, not only caused by a slow CPU or high CPU usage by other process, etc. also because a write cache is missing for NTFS estructure changes and that cause encryption multiple times the information that would be stored on the same place.

Hope i could open the eyes of someone about encryption... and hope VeraCrypt (the best in terms of security i have ever seen) would activate a NTFS write cache prior to encryption... it is very easy to do, just difere encryption of any cluster a little and if before end such time comes another write to that cluster, just ignore previous non-encrypted data... so encryption is done only once... in other words... a dynamic buffer prior to encryption.

Bad part for that is ... power lost, abrupt shutdown, etc... will make size of lost info to be a little more big... as if you use a HDD with 1GiB cache without a battery, etc... it is allways the race between speed or ensure write is done... i preffer speed for that, let me explain why...

If copying one millon small files (all in the same folder; windows really hates that, you are advised) tooks only 10 minutes (with write cache on at all levels) versus one week (write cache off at all levels)... do the maths yourself... that data is real life times, obtained by my self on abnormal tests i had done in the past to the NTFS system (FAT32 was a lot faster).

The maths are: what is the risk of needing power for only ten minutes versus for one whole week? what much will i loose? in case cache is on, i can loose 1/600 of the data (more or less); in case the cache is off i can loose only the file it was working on at that moment... but in both cases i will need to do a compare (full compare since file name can be on dir, but content may differ), so i will need near the same time to ensure all is well copied... i preffer to waste 10 minutes, than need one week to compare and see what is miss or different content, etc.

And in general, if loose for you is not an option... just to start you would not be using windows, neither FAT32, NTFS, etc... would be using at least Linux and Ext3/4 (journaling) and a power generator, etc.

So, please VeraCrypt, put that write buffer of NTFS as soon as can be.

Final note: FAT32 is affected by the same concept... it is not only NTFS... it is the way windows asks for directoies changes when files are created or deleted.

Do this test to see how speed goes done... in a lop create ten thousand files of ZERO size... take note of the speed / time the first 100 takes, versus how much time tooks another 100 when in the middle or the end... you really will see one file per minute (in some not so high speed CPUs)... ah! do it on a ramdrive (to ensure HDD does not affect speed).

Now to finish... i could not resist to do the same tests on Linux (over a Ext4 partition that resides on a VeraCrypt volume)... remember on Linux all are devices... so VeraCrypt presents to the kernel a device... so write cache can be on on both levels, Ext4 level and physical cluster writting... and by default Linux have all them allways on.

In Linux it really flies... as supposed to do since write cache is on, on both devices, the one that is normally mounted on /media/veracrypt# and the one that is physical /dev/sd$# (if talking about encryption a physical partition).

But, hey, VeraCrypt does not have a write buffer for Ext4 changes, no, it is Linux the one that has it... also more important... the period of time something is not sent to disk is reset as soon as another write goes to it; some linux have a top limit and send the data to the disk passed that one, but other Linux do not and can not send data to disk for years, in case for example when a cluster is written twice per second, each second of a full year, that cluster on such year could never ever have been writted to physical disk.

So on Linux, is Linux the one that is not sending more than once, the folder list (if changes on it are made in short time, like creating a lot of files on same folder, as when copying, etc), so VeraCrypt will only do the encryption once, after all files are set inside the folder list of files... etc. A lot, lot faster, than encrypting the whole dir list of files after each file is added.

Finish think: Windows hates, Linux love... or not, Linux tends to loose a lot of info is power is lost, much more than Windows... just because it has write chache... what is better? speed? or be secure writes are done? took 10 minutes to copy all, or one week? some preffer one, others preffer other... it is up to you.

But at least, i hope i had clarified why copying a lot of small files can be so slow (in Windows of course) to an Encrypted container (disk, partition, file, etc.) versus to the physical device when not encrypted.

Modern CPU are very fast.. Even previous generation of AMD FX-8350 with hardware AES support performs 5Gb/s with VeraCrypt v1.19 AES-256.

Most likely 2nd USB drive cannot perform better. It can be for example USB 2.0 drive.

In any case I recommend to spend some time for tests side-by-side.. You will have much more information.. and maybe you will be able to help somebody else.

To further complete what's been said so far:

VeraCrypt seems to have serious performance-wise disadvantages compared to some other solutions (Here and here). The referenced pages are mainly titled "...SSD...", but the contents describe multiple cases of performance degradation with conventional HDDs and more complex configurations (RAID/etc.). The serious cases seem to be due to (a) suboptimal coding or (b) security-savvy configuration decisions by VeraCrypt's community. The rest of this post is about (b).

IMPORTANT NOTE Some important parameters must be considered, investigated and normalized before comparing different solutions available:

1. Some of the performance keep seen by other solutions might be due to the fact that they're (almost?) completely offloading the cryptographic operations to the device itself which is very bad esp. after some recent reports. See this and this from Microsoft. The disclosed research has been focused on BitLocker but some other solutions may be doing the same.
2. More importantly, as others have pointed out, lower security margins can be the cause for some/most of performance improvement (e.g. fewer default hash iterations, smaller default key length, mode of operation, etc.).