Performance and Encryption goals – can you really have it all?

My time in Amsterdam is coming to an end. Not only did Allison and I explore a lot, but we also learned a lot and are now finalising our projects. So, for one last time, I guess it’s time to tell you what I’ve been up to for the last few weeks.

I want to start off talking a bit about encryption. There are different encryption algorithms and encryption modes. The algorithms I looked at in my project were AES, Twofish, Serpent and CAST5. The differences between them are not too important, so instead, let’s take a look at their most significant similarities:

1. they all remain unbroken and are therefore secure, and
2. they are all block ciphers.

The term blockcipher refers to the idea of splitting a plaintext that you want to encode into blocks of the same length and encrypting them seperately. This is necessary because otherwise, you would always need a key of the same length as the plaintext. If you’re not sure why that is, take a look at the Vernam cipher. By encrypting blocks of a determined length, you only need a key of that exact length and can use it for all of the blocks. There are different ways of applying a key to a block, i.e. different encryption modes. In my benchmarks, I looked at three such modes, namely ECB, CBC and XTS. The following is a short overview of these modes.

• 

• 

• 

ECB: The Electronic Code Book mode is the simplest and fastest way to encrypt blocks of plaintext. Every block is encrypted separately with the chosen algorithm using the key provided. This can be done in parallel. However, it is highly deterministic: identical plaintexts have identical ciphertexts.

CBC: The Cipher Block Chaining mode is less deterministic, but slower. The encryption is randomised by using an initialisation vector to encrypt the first block. Every subsequent block’s encryption depends on the block before, i.e. also on the initialisation vector. This cannot be done in parallel.

And finally, XTS: The XEX-based tweaked-codebook mode with ciphertext stealing uses two keys: The first one is itself encrypted by an initialisation variable and diffuses both the plaintext and the ciphertext of every block. It is also changed slightly for every block. The second key is used for actually encrypting the block. XTS also uses ciphertext stealing which is a technique for when the data length is not divisible by the block size: The plaintext of the last block is padded with the ciphertext from the previous block. Again, this mode can work in parallel.

Now you have a basic idea of what to consider when encrypting a disk: Not only are there different algorithms, but also different modes. Since they work quite differently, they might also have a different impact on the performance. To look into this, I set up a simple test environment out of two virtual machines: One acts as the host for the virtual machine to be benchmarked, and one acts as an NFS-Server which contains the encrypted disk. For more details on this, I suggest you have a look at my final report.

To benchmark the setup, I transcoded a 17-minute-long video of a German news programme. I did this on eight differently configured virtual disks: seven that were each encrypted differently, and one that was not encrypted. In every configuration, five runs were performed. I plotted the results in the following two graphs, and the configurations were:

Configuration No.	cipher	mode	key size	hash function
1	None	None	None	None
2	AES	ECB	256	SHA256
3	AES	XTS	256	SHA256
4	AES	CBC	256	SHA256
5	AES	CBC	128	SHA256
6	Twofish	CBC	256	SHA256
7	Serpent	CBC	256	SHA256
8	CAST5	CBC	128	SHA256

Here you can see how the encryption impacted the user performance. The non-encrypted setup is the green bar at the bottom. The impact of encryption on the user time is very low; the time needed is only increased by 0.5 to 3 percent.

Things look different in system time: The performance is decreased by 13-30%. While this sounds like a lot, it is not completely crazy; if you really need to secure your data, you’ll be okay with it. Also, the system time takes up only a small part of the real time.

Looking back at the process, I can say it is fairly simple to set up an encrypted disk for a virtual machine. The benchmark results show that the encryption does impact the performance, but only to a moderate extent. Also, they suggest that performance demands can be balanced with security demands since different configurations of the encryption lead to different timings. So basically, yes, you can have it all!