📅 February 27, 2017
“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.
VeraCrypt provides a built-in benchmark test to find out how the various encryption algorithms perform on a given system.
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 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
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.
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.
What is the format speed for each algorithm?
100x10M Disks Benchmark for 7GB Encrypted File Container
5GB File Container Copy Performance by Algorithm
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.
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.
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.