VeraCrypt and Encryption Algorithm Performance

đź“… February 27, 2017
cover“Does VeraCrypt slow down reads and writes?”

Do you want to encrypt your data, but are you concerned about a performance drop?

I was curious to find out if using VeraCrypt resulted in slower reads and writes for whole disk encryption with an external USB drive and for a standard file container, so I performed my own tests in Linux Mint 18.1.

How would the different encryption algorithms affect performance? Are some faster or slower than others?

Here are my results…


For those new to disk encryption, VeraCrypt is a free, cross-platform, on-the-fly encryption system that operates transparently. You can encrypt an entire hard drive/partition or create an encrypted file container that is mounted like a hard drive.

Once set up, you can format/read/write/delete like any other hard drive. All data on the VeraCrypt device is automatically encrypted/decrypted as needed. VeraCrypt volumes can be read in other operating systems, so you are not tied to a specific operating system product. As long as your system has VeraCrypt installed and as long as your operating system can read the formatted file system of the VeraCrypt volume, you can access your data. Sweet stuff.

Other encryption systems exist, but VeraCrypt is based on the earlier TrueCrypt that underwent a security audit some time ago. The audit results were quite good if not perfect, and VeraCrypt picks up where TrueCrypt left off.

For this test, I am using VeraCrypt 1.19 in Linux Mint 18.1. Since VeraCrypt is CPU-intensive, I used a test system containing the fastest CPU I had available: an i7 CPU.

Whole Drive Encryption Test

“Does whole disk encryption affect read/write performance on an external USB drive?”

USB devices benefit most from encryption since they are portable (translation: easy to lose), so this is a worthwhile question to answer.

With whole disk encryption, VeraCrypt encrypts the entire drive. There is absolutely nothing on the encrypted drive to identify it. In fact, if you connect an encrypted drive to Windows, you will be prompted to format it, so be careful on Windows systems.

For this test, I am using an external Seagate Ultra Slim+ USB drive connected to a USB 3.1 (USB 3.0 Gen 2) port. For reference, here is the performance of the USB drive without encryption.


Seagate Ultra Slim+ performance in Windows 7. Tested with CrystalDiskMark 5.1.2. Here, it is formatted as NTFS.


Same unencrypted USB drive, but this time formatted as ext4 in Linux Mint 18.1. This is the Disks benchmark. For some reason, the read/write performance is reported as slower than CrystalDiskMark.

Encryption Benchmarks

VeraCrypt provides a built-in benchmark test to find out how the various encryption algorithms perform on a given system.


VeraCrypt 1.19 10 MB encryption benchmark results with a medium-range i7 CPU.

Note that these numbers are dependent upon the speed of the CPU, not the hard drive. As more encryption algorithms are layered, the encryption/decryption speed decreases. This is normal because more CPU activity is required.

The Test

The goal was to format the entire drive as ext4 with VeraCrypt using most of the available encryption algorithms. Each algorithm received its own ext4 format. Then, I performed two tests. Using sync, time, and cp at the command line, I copied a 5GB file TO and FROM the encrypted USB volume and a fast M.2 SSD. The second test involved the Disks benchmark utility in Linux Mint 18.1.

100x10M Disks Benchmarks by Algorithm


Seagate Ultra Slim+ Disks Benchmarks with VeraCrypt 1.19.


5 GB File Copy Test

This tests real-world file transfer performance. Benchmarks are fine, but what can we expect from everyday usage? Copies were performed at the command line using sync (to complete any pending writes) and time to record the real, elapsed time of the copy using cp. Multiple copies were performed and averaged.


How long does it take to read and write a 5 GB file FROM and TO the encrypted Ultra Slim+ using various algorithms? Whole disk encryption with the ext4 file system.

If you look at the numbers carefully, some results do not make sense. For example, a plain, unencrypted drive takes longer to write 5GB than an encrypted drive. Nonetheless, these were the numbers I measured.

In all cases, the read speed were fairly consistent and remained the same across all algorithms. This makes sense because the USB drive is a mechanical drive (probably 5400 RPM), and it cannot supply data fast enough to exceed the decryption speed of the CPU. A slower CPU might produce slower results.

File Container Encryption Test

VeraCrypt allows you to create a file container. This is a regular file on the hard drive that is mounted as an encrypted volume. Think of it as a drive within a drive. This is not whole disk encryption.

Would there be a difference in speed? The source/destination drive was a Samsung 950 Pro M.2 NVMe in order to avoid the physical drive being the limiting factor. The M.2 SSD contained both the encrypted file and the 5 GB test file named data.bin for copy test purposes.

For this test, I created a fresh 7 GB file container for each algorithm formatted as ext4.


7 GB VeraCrypt standard file container mounted as /media/veracrypt3.


In Disks (for this test), we must select /dev/mapper/veracrypt3 in order to benchmark the encrypted file container.


Format Times

What is the format speed for each algorithm?


Format speeds by algorithm in MB/s. Yes, the chosen algorithm makes a difference. These numbers were recorded from VeraCrypt’s format dialog at 99% completion during the format.


100x10M Disks Benchmark for 7GB Encrypted File Container


Disks benchmark by algorithm using VeraCrypt 1.19 in Linux Mint 18.1. A new 7 GB VeraCrypt file container was created for each test.


Average Disks results by algorithm. The Kuznyechik read result is clearly incorrect compared to real-life performance, but this is what was recorded. Oh, well.

5GB File Container Copy Performance by Algorithm


Here are the read/write results when copying a 5GB file to and from a 7GB encrypted volume. Time is in seconds. Lower numbers mean faster file copies. A fresh 7GB encrypted volume was created for each algorithm test.


The Kuznyechik results were strange and difficult to assess accurately. First of all, this is the only algorithm that does not mount in /media. VeraCrypt mounts it as a loopback device in /tmp/.veracrypt_aux_mnt3/volume.


Encrypted 7GB Kuznyechik volume mounted for use. Its mount point is different from the other encryption algorithms.

This was unexpected, and it might explain why Disks reported Kuznyechik reads at 4.4 to 5 GB/s. This cannot be possible since the VeraCrypt benchmark utility reports a maximum of 560 MB/s for decryption. Something is happening here with this particular algorithm.

For the 5GB file copy test on the 7GB volume, each write test took 57 seconds to complete, but reads completed in ~12 seconds.

Benchmark Notes

VeraCrypt benchmarks are tricky to measure accurately, so the numbers shown above for whole disk encryption and encrypted file containers are best interpreted as guidelines, not absolute values. Combined with the built-in Linux caching mechanism (not RapidDisk), Disks would report wildly different numbers for the same algorithm that would increase with each successive run. (For example, AES: 1st run: 2.4GB/s read. 2nd run:  4.0 GB/s read.)

Write benchmarks remained mostly the same, so these numbers are reasonable. However, the reads varied too much, so I chose the lowest read result from each test in order to remain consistent with real-life expectations and to avoid hype.

For the file copy tests, I performed multiple writes and reads of the same 5GB data.bin file and then averaged the results to create the bar graphs.


So, does the chosen VeraCrypt algorithm affect read/write performance? Yes, but not by much. VeraCrypt’s encryption (writing) and decryption (reading) speeds are affected mainly by the speed of the CPU, not the hard drive unless you are using SSD or M.2 NVMe.

In all cases, read speeds were identical at ~10 seconds no matter which algorithm was chosen. Even triple-layered encryption schemes (AES-Twofish-Serpent) read 5GB files in ~10 seconds for both the mechanical drive and the M.2 file container.

Writes can vary depending upon the storage device. With M.2 file containers, a 5GB file writes in about 8-9 seconds according to time. This remained consistent no matter which algorithm was chosen. But with the external USB drive, write times varied by algorithm. So, yes, the algorithm does affect the write speed.

The initial format speed (by VeraCrypt) also depends upon the chosen algorithm. However, a format is only performed once, so this is not a major factor.

These results were interesting. Logically, layered algorithms should result in slower performance, but this was not the case except when writing to an encrypted mechanical USB drive. So, use whichever algorithm you like the best. If you need the security offered by layered encryption, then go ahead and use Serpent(AES) or AES(Twofish(Serpent)) without concern for a performance loss.

From everyday usage, I cannot notice much of a read/write speed difference among the various algorithms except when writing data to a mechanical drive and during VeraCrypt formatting. Just keep in mind that the more encryption layers that you use, the more your CPU must work, so think about CPU usage should you ever need to access your encrypted data from a slower computer.



  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: