Performance comparison of various encryption systems for linux
In this article I will try to compare the performance of various encryption systems under linux. In theory, of course, it is known which system is more productive, and attempts to calculate the performance of different systems were ( for example ). Truecrypt even contains a built-in benchmark (which shows, however, performance on RAM, it can only be used to estimate the speed of different encryption algorithms). I will do something different - I measure the speed of the file system, encrypted using different means, as a percentage of the usual unencrypted file system.
We will encrypt a separate partition on a separate HDD, which does not contain the root file system, by the algorithm used by default in each specific case. As a regular user, I don’t understand the nuances of encryption standards (for example, how does the RIPEMD-160 hashing from Whirpool differ, which of these modes is faster, and which contributes to higher protection), so we just rely on the fact that the manufacturers of each software product chose sufficiently robust default options. Maybe this is not entirely correct, because the performance of different encryption algorithms is not the same. If you wish, of course, you can change the type of encryption, but I'm not sure that there is an absolutely identical set of algorithms in all tested products. We will test:
1) LUKS is a native encryption system, in theory it should be the fastest. LUKS encrypted volumes can be used on Windows via FreeOTFE.
2) Truecrypt - unlike LUKS, it has, in addition to the console, a GUI interface, which makes it much easier to use. Multiplatform software. Providing two levels of plausible denial of the presence of encrypted data, necessary in case of a forced opening of the password by the user. Truecrypt volumes do not have a header; they cannot be distinguished from a set of random data. In theory, slower than LUKS, because uses FUSE.
')
3) eCryptfs is the default system offered by Ubuntu users to encrypt home directories, and therefore is included in this test. Works on top of an existing FS. Encrypts each file separately, so everyone can see the rights, modification dates, the number of encrypted files; by default, file names are also visible, although there is an option to encrypt them. The least functional tool from the presented.
4) EncFS is an approximate analogue of eCryptfs, but uses FUSE.
So, for tests, a separate old age machine is allocated in the following configuration: CPU - Intel Celeron 2000Mhz, RAM - 512 Mb DDR PC2700, system HDD - WD Caviar SE 5400 RPM 80Gb, test HDD - WD Caviar SE 7200 RPM 80Gb.
OS - Ubuntu 12.04 LTS, versions of all software relevant to the repositories of this OS at the time of this writing (Truecrypt 7.1a-linux-x86 is not from the repositories).
We will test the default ext4 file system for most distributions. For performance testing, we will use the iozone3 utility and a shell script written “on the knee” to measure the percentage difference in tests.
Under the spoiler, I will tell you more about the testing algorithm, so that everyone can conduct the test that interests him.
We rely on the -a mode, in which iozone should automatically perform a series of tests that cover all sorts of operations with files of different sizes and different recording lengths (my version produced 1638 tests).
During the experiment, it turned out that one series of iozone tests may differ by 5% in performance, so I will not rely on the results of a single test suite and do this: conduct a test suite several times and generate a file with averaged values ​​for each from tests (in all calculations of this article, averaged values ​​are the arithmetic mean value). After that, I compare the average file containing a series of tests on an unencrypted file system with a similar file containing a series of tests on an encrypted filesystem in this way: each test of the first file will be compared with the corresponding test of the second in percentage, the results will be added, and the amount divided by the number of tests By obtaining the arithmetic mean value, by how many percent the first group of tests is faster or slower than the second.
Also, for a simple estimate of speed, in addition to the above calculations, we will conduct a simple test - copying dd 500 megabytes from urandom to an encrypted filesystem with blocks equal to the default ext4 cluster size (4 kilobytes). dd if = / dev / urandom of = testfile bs = 4k count = 128000. The entire section will be encrypted (except for eCryptfs, which is not able to do this). I will not give commands for each case, I will show only the results.
So let's get started:
1) Encryption system: no
Number of test runs: 14
Average performance difference between the same test series: 1.3%
Result dd: 524288000 bytes (524 MB) copied, 187.823 s, 2.8 MB / s
2) Encryption system: LUKS. Using the default keys, our volume will be encrypted like this:
Cipher name: aes
Cipher mode: cbc-essiv: sha256
Hash spec: sha1
Number of test runs: 8
Average performance difference between the same test series: 1.4%
Result dd: 524288000 bytes (524 MB) copied, 199.505 s, 2.6 MB / s
Decline in performance compared to unencrypted FS: 7.9%
3) Encryption system: Truecrypt. Using all the default parameters, the volume will be encrypted with AES with the RIPEMD-160 hash algorithm.
Number of test runs: 22
Average performance difference between the same test series: 3.2%
Result dd: 524288000 bytes (524 MB) copied, 199.719 s, 2.6 MB / s
Performance drop compared to unencrypted FS: 7%
4) Encryption system: eCryptfs
aes: blocksize = 16; keysize = 16
Number of test runs: 9
Average performance difference between the same test series: 0.9%
Dd result: 524288000 bytes (524 MB) copied, 199.624 s, 2.6 MB / s
Performance drop compared to unencrypted FS: 49.5%
5) Encryption system: EncFS
Applying the preset paranoia mode, the following settings will be used:
Cipher: AES
Key Size: 256 bits
PBKDF2 with 3 second runtime, 160 bit salt
Filesystem Block Size: 1024 bytes
Filename Encoding: Block encoding with IV chaining
Unique initialization vector file headers
Message Authentication Code block headers
External IV Chaining
Number of test runs: 5
Average performance difference between the same test series: 0.7%
Result dd: 524288000 bytes (524 MB) copied, 293.656 s, 1.8 MB / s
Performance drop compared to unencrypted FS: 94.5%
Bottom line: EncFS showed the worst result. The performance of eCryptfs for all sorts of file operations leaves much to be desired, although the usual dd test with the optimal block size shows a speed similar to other encryption systems. I wouldn't cipher my entire home directory. It is convenient to use only when encrypting individual subdirectories. The expectations of lower Truecrypt performance due to the use of FUSE did not materialize, in my case it turned out to be even slightly faster than LUKS.
In addition, as a bonus, I will give a similar test dd for Truecrypt and LUKS, but for the file-hosted container (all encryption parameters are similar).
1) LUKS
524288000 bytes (524 MB) copied, 207.07 s, 2.5 MB / s
2) Truecrypt
524288000 bytes (524 MB) copied, 205.046 s, 2.6 MB / s
The drop in performance can be explained by the fact that there are additional overhead costs for reading the container file from an already existing file system instead of directly accessing the partition.
PS Added EncFS.
PPS Added a detailed description of the testing algorithm.
We will encrypt a separate partition on a separate HDD, which does not contain the root file system, by the algorithm used by default in each specific case. As a regular user, I don’t understand the nuances of encryption standards (for example, how does the RIPEMD-160 hashing from Whirpool differ, which of these modes is faster, and which contributes to higher protection), so we just rely on the fact that the manufacturers of each software product chose sufficiently robust default options. Maybe this is not entirely correct, because the performance of different encryption algorithms is not the same. If you wish, of course, you can change the type of encryption, but I'm not sure that there is an absolutely identical set of algorithms in all tested products. We will test:
1) LUKS is a native encryption system, in theory it should be the fastest. LUKS encrypted volumes can be used on Windows via FreeOTFE.
2) Truecrypt - unlike LUKS, it has, in addition to the console, a GUI interface, which makes it much easier to use. Multiplatform software. Providing two levels of plausible denial of the presence of encrypted data, necessary in case of a forced opening of the password by the user. Truecrypt volumes do not have a header; they cannot be distinguished from a set of random data. In theory, slower than LUKS, because uses FUSE.
')
3) eCryptfs is the default system offered by Ubuntu users to encrypt home directories, and therefore is included in this test. Works on top of an existing FS. Encrypts each file separately, so everyone can see the rights, modification dates, the number of encrypted files; by default, file names are also visible, although there is an option to encrypt them. The least functional tool from the presented.
4) EncFS is an approximate analogue of eCryptfs, but uses FUSE.
So, for tests, a separate old age machine is allocated in the following configuration: CPU - Intel Celeron 2000Mhz, RAM - 512 Mb DDR PC2700, system HDD - WD Caviar SE 5400 RPM 80Gb, test HDD - WD Caviar SE 7200 RPM 80Gb.
OS - Ubuntu 12.04 LTS, versions of all software relevant to the repositories of this OS at the time of this writing (Truecrypt 7.1a-linux-x86 is not from the repositories).
We will test the default ext4 file system for most distributions. For performance testing, we will use the iozone3 utility and a shell script written “on the knee” to measure the percentage difference in tests.
Script for counting. Special attention was paid to the purity of the code, the only criterion for writing was the presence of the correct result.
#!/bin/sh gendifffile () { # , . -, # ; -, , # ; -, - # cat $1 | while read LINE ; do echo $LINE| grep "^[[:space:]]*[[:digit:]]" | awk '{for (i=3;i<=NF;i++) {print $i}}' done >> $2 } getline () { # $2 $1 head -n $2 "$1" | tail -n 1 } compare () { # $1 $2, # , #, , , P=0 MAX=0 L1=`cat "$1" | wc -l` # L2=`cat "$2" | wc -l` if [ $L1 -ne $L2 ]; then # , echo error return fi STEP=$(( $L1*5/100 )) J=0 for I in `seq 1 $L1`; do J=$(( $J+1 )) if [ $J -eq $STEP ]; then J=0 echo "$(( 100*$I/$L1 ))% ($I $L1)" fi A=`getline "$1" $I` B=`getline "$2" $I` if [ `echo $A \> $B|bc -l` -eq 1 ]; then D=`echo "100-($B*100/$A)"|bc -l` if [ `echo $D \> $MAX| bc -l` -eq "1" ]; then MAX=$D sleep 5 fi else D=`echo "100-($A*100/$B)"|bc -l` if [ `echo $D \> $MAX| bc -l` -eq "1" ]; then MAX=$D sleep 5 fi D="-$D" # "-", , # , fi P=`echo "$P+$D"| bc -l` done P=`echo $P/$L1| bc -l` # echo PERCENT=$P MAX_PERCENT=$MAX } genaverage () { # , # , AVG=`mktemp` F=`ls "$1"|wc -l` # # , # if [ ! -d "$1" -o $F -lt 2 ]; then echo error >/dev/stderr # stderr, .. #stdout rm -f $AVG exit fi TMP=`mktemp` find "$1" -type f| while read FILE; do # iozone, I=`mktemp` # , gendifffile "$FILE" "$I" # "TMP" echo "$I">>$TMP done L=`cat \`getline "$TMP" 1\`|wc -l` cat "$TMP"| while read LINE; do # L1=`cat "$LINE"| wc -l` # if [ $L -ne $L1 ]; then echo error >/dev/stderr exit fi done STEP=$(( $L*5/100 )) J=0 for I in `seq 1 $L`; do J=$(( $J+1 )) if [ $J -eq $STEP ]; then J=0 echo "$(( 100*$I/$L ))% ($I $L)" >/dev/stderr fi SUMFILE=`mktemp` # SUM SUM=0 cat "$TMP"| while read LINE; do SUM=$(( `getline "$LINE" $I`+$SUM )) echo $SUM > "$SUMFILE" done echo `tail -n 1 "$SUMFILE"`/$F|bc -l >> $AVG # # # AVG rm -f "$SUMFILE" done cat "$TMP"| while read LINE; do # e rm -f "$LINE" done rm -f "$TMP" echo $AVG } printf %b "\\033[1;31m 1/3\n" printf %b "\\033[1;37m" echo \""$1"\" A=`genaverage "$1"` printf %b "\\033[1;31m 2/3\n" printf %b "\\033[1;37m" echo \""$2"\" B=`genaverage "$2"` printf %b "\\033[1;31m 3/3\n" printf %b "\\033[1;37m" echo compare "$A" "$B" rm -f $A $B Under the spoiler, I will tell you more about the testing algorithm, so that everyone can conduct the test that interests him.
testing algorithm
1) we connect the tested unencrypted partition to the mount point, go to it, run the iozone test series
We run as many laps as we don’t mind. The larger the number, the more accurate the result. For some types of dough (for the slowest), a large number of circles does not matter, enough is 5.
Add the results to a separate directory, let's call it, for example, unencrypted.
2) encrypt the partition, connect to the mount point, similarly run a series of tests, add the results to another directory (for example, encrypted).
3) run the counting script, passing it the names of both directories as parameters. The script will display a certain number, by what percentage, on average, the difference in performance between the reports of the first and second directories. If the number is> 0, then the reports of the first directory are faster by this number of percent; and vice versa, if the number is <0, it means slower.
i=0 while true; do i=$(( $i+1 )) echo i=$i time iozone -a >report$i echo sleeping 180 sleep 180 done We run as many laps as we don’t mind. The larger the number, the more accurate the result. For some types of dough (for the slowest), a large number of circles does not matter, enough is 5.
Add the results to a separate directory, let's call it, for example, unencrypted.
2) encrypt the partition, connect to the mount point, similarly run a series of tests, add the results to another directory (for example, encrypted).
3) run the counting script, passing it the names of both directories as parameters. The script will display a certain number, by what percentage, on average, the difference in performance between the reports of the first and second directories. If the number is> 0, then the reports of the first directory are faster by this number of percent; and vice versa, if the number is <0, it means slower.
We rely on the -a mode, in which iozone should automatically perform a series of tests that cover all sorts of operations with files of different sizes and different recording lengths (my version produced 1638 tests).
During the experiment, it turned out that one series of iozone tests may differ by 5% in performance, so I will not rely on the results of a single test suite and do this: conduct a test suite several times and generate a file with averaged values ​​for each from tests (in all calculations of this article, averaged values ​​are the arithmetic mean value). After that, I compare the average file containing a series of tests on an unencrypted file system with a similar file containing a series of tests on an encrypted filesystem in this way: each test of the first file will be compared with the corresponding test of the second in percentage, the results will be added, and the amount divided by the number of tests By obtaining the arithmetic mean value, by how many percent the first group of tests is faster or slower than the second.
Also, for a simple estimate of speed, in addition to the above calculations, we will conduct a simple test - copying dd 500 megabytes from urandom to an encrypted filesystem with blocks equal to the default ext4 cluster size (4 kilobytes). dd if = / dev / urandom of = testfile bs = 4k count = 128000. The entire section will be encrypted (except for eCryptfs, which is not able to do this). I will not give commands for each case, I will show only the results.
So let's get started:
1) Encryption system: no
Number of test runs: 14
Average performance difference between the same test series: 1.3%
Result dd: 524288000 bytes (524 MB) copied, 187.823 s, 2.8 MB / s
2) Encryption system: LUKS. Using the default keys, our volume will be encrypted like this:
Cipher name: aes
Cipher mode: cbc-essiv: sha256
Hash spec: sha1
Number of test runs: 8
Average performance difference between the same test series: 1.4%
Result dd: 524288000 bytes (524 MB) copied, 199.505 s, 2.6 MB / s
Decline in performance compared to unencrypted FS: 7.9%
3) Encryption system: Truecrypt. Using all the default parameters, the volume will be encrypted with AES with the RIPEMD-160 hash algorithm.
Number of test runs: 22
Average performance difference between the same test series: 3.2%
Result dd: 524288000 bytes (524 MB) copied, 199.719 s, 2.6 MB / s
Performance drop compared to unencrypted FS: 7%
4) Encryption system: eCryptfs
aes: blocksize = 16; keysize = 16
Number of test runs: 9
Average performance difference between the same test series: 0.9%
Dd result: 524288000 bytes (524 MB) copied, 199.624 s, 2.6 MB / s
Performance drop compared to unencrypted FS: 49.5%
5) Encryption system: EncFS
Applying the preset paranoia mode, the following settings will be used:
Cipher: AES
Key Size: 256 bits
PBKDF2 with 3 second runtime, 160 bit salt
Filesystem Block Size: 1024 bytes
Filename Encoding: Block encoding with IV chaining
Unique initialization vector file headers
Message Authentication Code block headers
External IV Chaining
Number of test runs: 5
Average performance difference between the same test series: 0.7%
Result dd: 524288000 bytes (524 MB) copied, 293.656 s, 1.8 MB / s
Performance drop compared to unencrypted FS: 94.5%
Bottom line: EncFS showed the worst result. The performance of eCryptfs for all sorts of file operations leaves much to be desired, although the usual dd test with the optimal block size shows a speed similar to other encryption systems. I wouldn't cipher my entire home directory. It is convenient to use only when encrypting individual subdirectories. The expectations of lower Truecrypt performance due to the use of FUSE did not materialize, in my case it turned out to be even slightly faster than LUKS.
In addition, as a bonus, I will give a similar test dd for Truecrypt and LUKS, but for the file-hosted container (all encryption parameters are similar).
1) LUKS
524288000 bytes (524 MB) copied, 207.07 s, 2.5 MB / s
2) Truecrypt
524288000 bytes (524 MB) copied, 205.046 s, 2.6 MB / s
The drop in performance can be explained by the fact that there are additional overhead costs for reading the container file from an already existing file system instead of directly accessing the partition.
PS Added EncFS.
PPS Added a detailed description of the testing algorithm.
Source: https://habr.com/ru/post/201694/
All Articles