eSTREAM in Linux: Salsa20

It was pointed out by Herbert Xu that I could achieve what I want with eSTREAM ciphers simply by using the blkcipher interface. The estream.c and stream.c were entirely redundant. So I gave his suggestion a try and it worked for Salsa20! The patch is available on this page. This approach is much more elegant and does not disturb the existing “ecosystem”.

I’ve renamed the posts’ title to “eSTREAM in Linux: <algo name>” as I am now submitting one patch for each cipher. Seems more sensible this way.

PS: It was also suggested to me that Salsa20 can also be implemented as ctr(salsa20,0,16,8) where ctr is the counter mode template and salsa20 is the Salsa20 expansion function. Initially I thought it was possible too but when I read through ctr.c, I realize I can’t specify the block size of the Salsa20 expansion function. Should it be the 16 (blocksize of input) or 64 (blocksize of output)? If 16, then crypto_ctr_crypt_{segment,inplace} will be walking in steps smaller than the output block size; if 64, then the test for ((noncesize + ivsize + countersize) < alg->cra_blocksize) will trigger an error.

PS (19 Nov): This is commit 9ea2097f7339a03cb149c70b512f755cf0a529da in the kernel now.

Advertisements

Porting eSTREAM ciphers into Linux: Part 2

After more experiments with the Linux kernel CryptoAPI, I find that the eSTREAM ciphers are a misfit. (This statement is not quite right as explained in the postscript at the end of this post.) The problem is that eSTREAM ciphers require a call to setiv() but cipher_alg and cipher_tfm do not provide such a callback.

The setiv() call is important for eSTREAM ciphers as most of them use it to mix the IV into their key expansion. This is very different from general block ciphers where the IV is handled at the “mode of operation” level and does not affect the cipher’s key expansion.

So I created a new crypto_type called crypto_estream_type (and the associated *_alg and *_tfm) to address the needs of eSTREAM ciphers. These patches (available here) pass the tcrypt regression test and seem to capture the semantics of eSTREAM ciphers better. Currently I am discussing with the veterans on linux-crypto@vger.kernel.org whether this is the right approach.

PS (14 Nov): I realized today that dm-crypt.c uses crypto_cipher directly so my patches will not work with dm-crypt. Bummer!

PS (15 Nov): Herbert Xu pointed out that I can achieve what I want to do using the blkcipher interface instead of the cipher interface. There is really no need for a new crypto_type. I think he is right so I will be giving it a try. (Note: Herbert is the current maintainer of the APIs and he developed many of these interfaces so he knows them much better than I do.)

Redundant whitespaces

It seems that Linux kernel developers do not like redundant whitespaces (e.g. trailing whitespaces, space in indent followed by tab). So if we are to submit a patch, it is a courtesy to remove these redundant whitespaces.

If we have git installed, we can check our patch using the following command suggested by Herbert Xu:

git apply --check --whitespace=error-all <patch filename>

Jan Engelhardt has an editor agnostic solution:

find . -type f -print0 | xargs -0 grep -Pn '[\t ]+$'

Kyle Moffett added the following to .vimrc to enable automatic highlighting:

" Show trailing whitespace and spaces before tabs
hi link localWhitespaceError Error
au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display
au Syntax * syn match localWhitespaceError / \+\ze\t/ display

Porting eSTREAM ciphers into Linux: Part 1

I’ve started to port eSTREAM candidate ciphers into the Linux kernel. So far I’ve successfully ported Salsa20. I’m aiming to port SOSEMANUK next. This is a work in progress. A more detailed description of the what, why and how is available here.

Currently eSTREAM is at Phase 3. Hopefully by May 2008 a final selection of stream ciphers will be made and what I am doing now will have greater utility for Linux users then. :-)