On-the-fly encryption performance

[Alex Railean]

Several people asked us if performance tests were made, in order to be able to compare the read/write speeds of encrypted partitions and non-encrypted ones.

Here are the results of a recently conducted experiment.

First of all, here is the set-up:
hardware
- AthlonXP 1.9GHz
- 2x256 RAM PC3200 (DDR400) [working in dual channel mode]
- A7N8X-E Deluxe [uses the nVidia nForce2 400 chipset]
- SATA hard drive, 8MB buffer [WD 2000JD]

software
- Windows XP SP1
- a desktop, the tests were performed while the PC was loaded in a usual way, that includes a running FTP server, a firewall that processes all the network activity, the network connection was active.

The virtual drive, the partition on which the image resides, and the partition to which the data were written [or from which they were read from] are all in FAT32; with a minimal level of file fragmentation [a disk defragmanter is running as a service and performs routine defragmentation when the CPU is idle]


The test was performed in several rounds, with two types of target-content:
a. a single ISO file [658 MB]
b. a pack of small files [a total of 2140, split into various subfolders] taken from a photo archive [all of them are in JPG format, here and there - several GIF, AVI and MOV files], the total size was 667 MB


Note that the computer was not especially prepared to handle a performance test (ex: all the non-necessary services, all the running and resource-consuming applications... were not turned off). These measures are not relevant in this case, because the purpose of the test was to determine the read/write speeds relative to read/write speeds of non-encrypted file transfers, in a usual production environment.

Here are the results: [time to complete the operation - average / maximum / minimum transfer rates]
------non encrypted [to be used as a reference of how the computer performs when encryption is not used
FAT32->FAT32 [i.e. non-encrypted to non-encrypted]

[a] 95s        average=6.92 MB/s   max=14 MB/s, min=3.8 MB/s
[b] 99s        average=6.73 MB/s        max=25 MB/s, min=2.4 MB/s

------encrypted
FAT32->AES [i.e. non-encrypted to encrypted partition]

[a] 101s        average=6.51 MB/s        max=10 MB/s, min=2.9 MB/s
[b] 124s     average=5.37 MB/s        max=14 MB/s, min=2.5 MB/s

AES->FAT32 [i.e. encrypted to non-encrypted]

[a] 158s        average=4.16 MB/s        max=7.5 MB/s, min=1 MB/s
[b] 115s        average=5.8 MB/s        max=20  MB/s, min=3.9 MB/s

MAX and MIN are the maximum and minimum transfer rates that were reached. This detail allows us to establish an important fact - the performance of the hardware itself plays a crucial role in the process, hence all the bottlenecks [if any] must be removed by tweaking the hardware.

AES is a symmetric cypher, encryption and decryption happen in the exact same way [but operations are applied in a reversed order], meaning that the cost of encryption is identical to the cost of decryption. Judging by the results, you can see that there is a difference between read\write speeds; since we know that this difference is NOT caused by the software level, we can conclude that it is the hardware that causes this.


Also, you will see that the average speeds do not differ too much, though there is an evident contrast between MAX and MIN rates. A high MAX rate indicates that our implementation can be rather fast, so the bottleneck is in the hardware. This is also confirmed by the fact that normally [i.e. without encryption] the read\write speed oscillates as well [though the bounds may be "tighter"].

Another aspect - there should not be a great difference between FAT->AES[a] and AES->FAT[a] (because AES is a symmetric cypher), yet we have 101s vs 158s. Again, this proves that performance is significantly dependent on the hardware.


Evidently, there will be different results if the same test is performed on a different computer; which is why I have to emphasize that my objective was to determine the relative difference between the two cases, so that you could estimate encryption performance by extrapolating from 'usual' performance.


One final note - the CPU load was always below average (regardless of the phase of the experiment).


Feel free to share the results of your tests, or discuss the ones that were obtained during the current test.