How to choose a stream cipher

Question

Are there high-speed ciphers designed for things like internet streams without sacrificing security? There are so many options that operate in stream mode. How would one choose a cipher?

Answer 1

By default use AES. AES is a block cipher, i.e. a function which, given a key, maps block values (of 128 bits, in the case of AES) to other block values of the same size. To encrypt a message, one must use the block cipher in a chaining mode which tells how the input data should be split and encrypted and assembled again. Almost all modes allow for streaming (encrypting a huge message on the go, without having to store it entirely in RAM or disk). The good modes combine encryption and integrity check, see EAX and GCM. Among traditional encryption-only modes, the current one is CBC, the newer being CTR; CTR has the advantage of not requiring padding, because it encrypts a sequence of x bytes into exactly x bytes, for all x, whereas CBC requires an input with a length multiple of the block size.

I have a 2.4 GHz Core2 Intel CPU on my PC. This is far from being the best available out there, and will soon verge on the "obsolete", at least commercially speaking. Nevertheless, when I run the OpenSSL benchmark tool:

$ openssl speed aes-128-cbc
(...)
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     108028.29k   147211.99k   161986.82k   166308.90k   167286.10k

so the processor can encrypt data at the whooping speed of 167 MB per second; and that's using a single core. My PC has four cores, so even encrypting data at the maximum bandwidth which could go through gigabit Ethernet would use only 15% of the CPU resources. It would take a quite special application to actually make encryption a bottleneck.

Things will go even an order of magnitude faster on a newer x86 processor, one with the AES-NI instructions. These instructions allow for encrypting data at a rate of less than 2 clock cycles per data byte; if you prefer, it goes beyond the gigabyte per second. Note that this is about 10 times faster than what a typical harddisk can do. The AES-NI instructions also include the pclmulqdq opcode, which helps quite a lot when dealing with the GCM mode.

Nevertheless, there are conceivable, specialized situations where the raw speed of AES is not sufficient (involving machines which do not have AES-NI instructions, of course). For these, one could remark that a block cipher is a versatile primitive, and that maybe an algorithm designed specifically to encrypt long streams, but unable to do anything else, could possibly crunch data a bit more faster. These are called stream ciphers. An old, well-known, slightly weak and actually not that fast stream cipher is RC4. The eSTREAM project ran from 2004 to 2008 as a kind of open competition, with stream cipher candidates and open comments and workshops, and resulted in a portfolio of stream ciphers which "look good" from both security and performance point of views (they did not receive at much scrutiny than AES, but they got a fair share nonetheless). There are four ciphers optimized for software platforms, and three for hardware designs. They are all unpatented and free for any use (Rabbit was patent pending, but in October 2008 it was released to public domain).

An example of application where a stream cipher gives an edge over a block cipher is actually not security related: this is heavy numeric simulation, which requires a steady stream of random values of high quality. Stream ciphers produce high-quality randomness (they are designed so that no bias can be found, even by looking for them on purpose, whereas custom non-cryptographic random number generators tend to rely on luck -- that the problem at hand does not happen to hit one of the known biases of the RNG). For such a purpose, I have successfully used Sosemanuk, one of the eSTREAM portfolio stream ciphers.

Either way, block ciphers and stream ciphers both need proper IV management. The IV is a parameter which needs not be secret, but which must have some specific properties. For some ciphers, it suffices that no two messages are ever encrypted with the same key and the same IV. Some others (including CBC mode) require a bit more, namely that the IV is chosen for each message with uniform probability among the space of possible IV. Anyway, the IV must be known by the receiver, so it is customary to send it in the header of the encrypted message. The RC4 stream cipher has no IV: a given key must never be used for more than one message. IV management is where you will have security issues, because it is often overlooked and not that easy to get right.

Summary: use AES with a proper encryption mode; you also need integrity checks, so a combined mode such as GCM is a good idea. Mind your IV. Envision switching to something else only if you find out that AES is an inevitable bottleneck, because there is very high probability that this will not turn out to be the case.