This patch implements a template that wraps around an eSTREAM cipher
algorithm and its ivsize.
For example, an eSTREAM cipher with the name CIPHERNAME and ivsize
IVSIZE will be instantiated as "stream(CIPHERNAME,IVSIZE)" in
cryptomgr. It uses blkcipher to walk over the memory it
encrypts/decrypts. It has been modified to use the crypto_estream_*
type instead of crypto_cipher_*.
Sorry I omitted the patch. Here it is.
On Nov 13, 2007 3:59 AM, Tan Swee Heng <[email protected]> wrote:
> This patch implements a template that wraps around an eSTREAM cipher
> algorithm and its ivsize.
>
> For example, an eSTREAM cipher with the name CIPHERNAME and ivsize
> IVSIZE will be instantiated as "stream(CIPHERNAME,IVSIZE)" in
> cryptomgr. It uses blkcipher to walk over the memory it
> encrypts/decrypts. It has been modified to use the crypto_estream_*
> type instead of crypto_cipher_*.
>
Tan Swee Heng <[email protected]> wrote:
> This patch implements a template that wraps around an eSTREAM cipher
> algorithm and its ivsize.
Why couldn't straem ciphers that require an IV just use the
blkcipher interface? Please enlighten me :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
On Nov 13, 2007 9:43 AM, Herbert Xu <[email protected]> wrote:
> Why couldn't straem ciphers that require an IV just use the
> blkcipher interface? Please enlighten me :)
>From what I understand, the blkcipher interface provides functions
like crypto_blkcipher_set_iv() for the caller to set IV. What it does
is to set *iv in blkcipher_tfm to point to the IV buffer. Later this
pointer is passed to desc->info and walk->iv. (Some caller like
dm-crypt.c sets desc->info = iv directly though.) Subsequently
templates like "cbc" and "ctr" pick up the IV pointer from walk->iv.
For "cbc", the IV is XORed into the input block before calling the
underlying cipher. For "ctr", the IV is used to form a counter block
before calling the underlying cipher.
In fact, my "stream" template patch uses blkcipher in the same way.
However unlike "cbc" and "ctr", "stream" cannot process the IV. It
must pass it to the underlying eSTREAM cipher's setiv() because each
cipher's setiv() manipulates the IV differently. (Salsa20 uses it in a
counter block; other eSTREAM ciphers mix the IV with the key in their
key expansion.)
So blkcipher is indeed fine for stream ciphers as you stated - I even
use it in "stream". The problem is that cipher_alg and cipher_tfm do
not have callbacks for eSTREAM ciphers to expose setiv(). The
"estream" patch tries to address this issue by introducing
crypto_estream_type, estream_alg and estream_tfm.
I hoped my explanation is clear. The difference in "set IV" semantics
for block modes and eSTREAM ciphers can be confusing. The patches I've
submitted recently are my solution to this problem. It is probably not
the best solution. If you or any other expert on this list have other
ideas, please discuss and I will try to implement them. (Although the
patches pass tcrypt and seem to embody eSTREAM ciphers rather well, I
just realized they are not usable in dm-crypt as dm-crypt.c explicitly
uses crypto_cipher. Bummer!)
Swee Heng
On Wed, Nov 14, 2007 at 01:25:37AM +0800, Tan Swee Heng wrote:
>
> In fact, my "stream" template patch uses blkcipher in the same way.
> However unlike "cbc" and "ctr", "stream" cannot process the IV. It
> must pass it to the underlying eSTREAM cipher's setiv() because each
> cipher's setiv() manipulates the IV differently. (Salsa20 uses it in a
> counter block; other eSTREAM ciphers mix the IV with the key in their
> key expansion.)
I think we're talking past each other :)
What I'm suggesting is that you implement the stream ciphers that
use an IV directly using the blkcipher interface, and not the cipher
interface. That way you can do whatever you want with the IV.
> So blkcipher is indeed fine for stream ciphers as you stated - I even
> use it in "stream". The problem is that cipher_alg and cipher_tfm do
> not have callbacks for eSTREAM ciphers to expose setiv(). The
> "estream" patch tries to address this issue by introducing
> crypto_estream_type, estream_alg and estream_tfm.
That's right. Apart from Salsa you shouldn't have to use the cipher
interface at all. Which means that what the cipher interface lacks
is not a problem :)
Salsa can use the cipher interface because deep down it's a block
cipher. It's just being used in counter mode.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
On Nov 14, 2007 11:07 AM, Herbert Xu <[email protected]> wrote:
> What I'm suggesting is that you implement the stream ciphers that
> use an IV directly using the blkcipher interface, and not the cipher
> interface. That way you can do whatever you want with the IV.
The "Ah-ha!" moment! :-) Finally I get what you are saying. Ok, sounds
like a good idea. I will try it out this evening and get back to you
when I am done.
> That's right. Apart from Salsa you shouldn't have to use the cipher
> interface at all. Which means that what the cipher interface lacks
> is not a problem :)
I was under the wrong impression that only the templates use the
blkcipher interface.
> Salsa can use the cipher interface because deep down it's a block
> cipher. It's just being used in counter mode.
I might still implement it using the blkcipher interface as it seems
strange to call it via "ctr(salsa20,..)" as it is meant to be a stream
cipher after all. I always find "ecb(arc4)" kind of strange. :-)
Swee Heng
On Thu, Nov 15, 2007 at 09:14:40AM +0800, Tan Swee Heng wrote:
>
> > Salsa can use the cipher interface because deep down it's a block
> > cipher. It's just being used in counter mode.
> I might still implement it using the blkcipher interface as it seems
> strange to call it via "ctr(salsa20,..)" as it is meant to be a stream
> cipher after all. I always find "ecb(arc4)" kind of strange. :-)
Actually what I suggested is that you add a wrapper called
salsa20 that then simply calls ctr(...) after constructing the
IV.
It's OK to have two algorithms of the same name provided that
their types are different. So you can have a salsa20 blkcipher
and also a salsa20 cipher.
We don't really need to have two copies of the ctr code under
crypto :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
On Nov 15, 2007 9:18 AM, Herbert Xu <[email protected]> wrote:
> Actually what I suggested is that you add a wrapper called
> salsa20 that then simply calls ctr(...) after constructing the IV.
I tried that but encountered a problem: what is the blocksize for the
underlying salsa20 expansion function. If 16 (block size of input)
then crypto_ctr_crypt_{inplace,segment} will be taking steps that are
too small. If 64 (block size of output) then we fail the ((noncesize +
ivsize + countersize) < alg->cra_blocksize) test in
crypto_crt_alloc(). It appears that ctr(salsa20,...) may not work or
am I missing something here?
> We don't really need to have two copies of the ctr code under crypto :)
Since I was unable to do ctr(salsa20,...) I simply let Bernstein's
original code handles the increment of the counter.
By the way, are there plans to collect the xor_{byte,quad,64,128}
functions into a common header, say include/crypto/xor_n.h? It would
be nice to have these common functions in a place where everyone can
use. Currently cbc, ctr, pcbc and xcbc each has their own
implementation. If it is useful to have such a header file, I can help
to put together it. (After all, I foresee that I will need them when
implementing other eSTREAM ciphers.)
Swee Heng