eSTREAM in Linux

This page documents my effort at porting eSTREAM ciphers into the Linux kernel. The tools and patches are over here.

The Linux kernel CryptoAPI

The Linux kernel provides a CryptoAPI framework for cryptographic primitives to be used from kernel space. Via this framework, we are able to protect IPSEC traffic and file systems. For example, if I am interested in creating an encrypted partition on /dev/sdb1 protected by AES in CBC mode with ESSIV generation using SHA256, I can simply perform:

cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sdb1

If I rather use Twofish in Counter mode with plain IV generation, I will use the following command instead:

cryptsetup luksFormat -c twofish-ctr-plain /dev/sdb1

Cool isn’t it? Part of the magic that makes this possible comes from the Linux CryptoAPI. If you are interested to find out more, you can drop by a good web archive of the linux-crypto@vger.kernel.org mailing list.

Supported block ciphers and modes

As of 2.6.24-rc1, the kernel supports the following block ciphers:

  • AES-128, AES-192, AES-256
  • Anubis
  • Blowfish
  • Camellia
  • CAST5, CAST6
  • DES, Triple DES (EDE)
  • FCrypt
  • Khazad
  • SEED
  • Serpent, Tnepres
  • TEA, XTEA, XETA
  • Twofish

It also supports many block mode of operations:

  • CBC (Cipher Block Chaining)
  • CTR (Counter)
  • ECB (Electronic Code Book)
  • LRW (Liskov Rivest Wagner)
  • PCBC (Propogating Cipher Block Chaining)
  • XCBC (eXtended Cipher Block Chaining)
  • XTS (XEX-based Tweaked code book mode with ciphertext Stealing; replaces LRW in IEEE P1619)

Where are the stream ciphers?

Well, there is actually one stream cipher in the CryptoAPI framework: the venerable RC4. (However it is accessed via ECB which is kind off peculiar given that RC4 is not a block cipher.)

And so it seems that the Linux kernel has an overwhelming preference for block ciphers over stream ciphers. That is not surprising given that much of the usage for ciphers are on block devices, e.g. dm-crypt for encrypting disk sectors, IPSEC for encrypting packets. (Google for “stream cipher IPSEC” and we find that there are some old draft RFCs for using stream ciphers in ESP which never got onto the STD track.)

Another reason could be that stream ciphers are perceived to be “less secure” since they are susceptible to watermarking attacks and reuse of keys and IVs can be catastrophic. But personally I don’t think that argument holds since the same can be said of CTR mode – and we do know that RFC 3686 is on the Standards Track, don’t we?

I believe the real reason is that currently there does not exist a “popular” standard for stream ciphers that is free of licensing issues. But that situation may change comes May 2008.

Enter eSTREAM

The eSTREAM project is the EU’s “multi-year effort to identify new stream ciphers that might become suitable for widespread adoption”. The eSTREAM ciphers fall into two broad profiles: software and hardware. Currently eSTREAM has entered Phase 3 with eight software candidates and eight hardware candidates.

The final report of eSTREAM is due in May 2008. Hopefully this time round a selection of stream ciphers will be made, unlike at NESSIE where all stream ciphers candidates were dropped. Also hopefully the selected stream ciphers will enjoy widespread adoption like AES. (Do you know that AES is so prevalent that it has entered your living room? It is implemented in your HDTV! Personally I think NIST did a really good job with AES: firstly, they attracted lots of attention by organizing a competition; secondly, they make life easy for developers by selecting exactly ONE candidate as AES; thirdly, AES is free for anyone to use.)

Supporting eSTREAM ciphers in the kernel

So I suppose now is a good time to port eSTREAM candidates into the kernel. In my free time (which is terribly limited nowadays) I’ve started to work towards that end. My latest patches are available below if you are interested to test it out.

My initial attempts involved creating an estream crypto_type and stream template to wrap around a salas20 crypto_alg. But it has been pointed out to me that I could have simply used the blkcipher interface to implement salsa20 instead of the cipher interface. That way, I do not need estream and stream. It was very good advice indeed and I’ve switched to blkcipher from now on.

Although it is kind of a misnomer to implement a stream cipher using a block cipher interface, it is only a detail for the developer. Users see the cipher as “salsa20” so there is no confusion really. Furthermore many of the eSTREAM software candidate do process data in blocks.

References

  1. The Linux Kernel Cryptographic API, http://www.linuxjournal.com/article/6451, James Morris, 01 Apr 2003. (PDF copy of page available here as 6451.pdf. Note that this document is somewhat dated and some of the interface has changed. However it provides good background on the design considerations that went into the API.)
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: