Added a "stream" template to support stream ciphers (eSTREAM
candidates in particular) within the CryptoAPI framework.
The current patch differed from my first posting (25 Oct) to the
mailing list in several ways:
1. It now uses cia_setiv() only instead of cia_setiv_crypt() in
include/linux/crypto.h. Reason: (a.) it is closer to the semantics of
eSTREAM's API; (b.) I want to avoid setting cia_encrypt and
cia_decrypt to NULL.
2. It uses a blocksize of 1 for stream (as suggested by Evgeniy)
3. It does not let the underlying cipher handle the full encryption of
the buffer any more. Instead it does it in chunks of the underlying
cipher's "block size", like the other block modes. (Most eSTREAM
software candidates seem to have a native "block size").
The current patch uses setkey(key, keylen) and setiv(iv, ivlen). The
eSTREAM's API actually requires setkey(key, keylen, ivlen) and
setiv(iv). The discrepancy arises because I am simply riding on the
existing "struct cipher_alg". I will look into how this discrepancy
can be resolved (perhaps by creating a separate "struct estream_alg").
Until this discrepancy is resolved, some of the eSTREAM ciphers like
SOSEMANUK may not be usable. Ciphers which have a fixed IV length
(e.g. Salsa20) are usable using the current patch.
Swee Heng
On Tue, Nov 06, 2007 at 07:37:20PM +0000, Tan Swee Heng wrote:
> Added a "stream" template to support stream ciphers (eSTREAM
> candidates in particular) within the CryptoAPI framework.
Thanks for the patch.
Having reviewed it and the specification of Salsa20 I think
we can already support an Salsa20 implementation without the
addition of this new interface.
In fact, thanks the work Joy has done with CTR, the Salsa20
stream cipher can be expressed as
ctr(salsa20,0,16,8)
where salsa20 is the Salsa20 expansion function.
So could you please update your patches so that it works under
this framework? So your salsa20 simple cipher should be OK as
it is minus the extra bits like setiv. Plus you should add a
block cipher salsa20 algorithm that just invokes the above CTR
algorithm and constructs the IV in the appropriate manner.
Thanks,
--
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, thanks for taking the time to review my patches. My reply is below.
On Nov 11, 2007 8:11 PM, Herbert Xu <[email protected]> wrote:
> In fact, thanks the work Joy has done with CTR, the Salsa20
> stream cipher can be expressed as
> ctr(salsa20,0,16,8)
> where salsa20 is the Salsa20 expansion function.
I agree that Salsa20 can be implemented this way as it is essentially
a hash function in counter mode. However this is not true in general
of other eSTREAM candidates. I am hoping to find a general solution
for eSTREAM ciphers, not just Salsa20.
> So could you please update your patches so that it works under
> this framework? So your salsa20 simple cipher should be OK as
> it is minus the extra bits like setiv.
I could do that. But before I do, may I propose an alternative approach?
I would like to propose using a separate crypto_type, say
crypto_estream_type, to "categorize" eSTREAM ciphers. Also separate
estream_alg and estream_tfm will be used to support the setiv() call
and to track the ivsize. A "stream" template will be used to specify
the algorithm and ivsize - so for example Salsa20 will be
"stream(salsa20,8)" to cryptomgr.
I think this is a valid approach as it allows eSTREAM ciphers to be
ported easily into the kernel without disturbing the existing block
ciphers and block modes. I also think it is feasible because I've
implemented it and tested it over the weekend. :P
Please consider the merits of such an approach. I will post my 3
patches in separate emails.
Regards,
Swee Heng
On Tue, Nov 13, 2007 at 03:44:42AM +0800, Tan Swee Heng wrote:
>
> I agree that Salsa20 can be implemented this way as it is essentially
> a hash function in counter mode. However this is not true in general
> of other eSTREAM candidates. I am hoping to find a general solution
> for eSTREAM ciphers, not just Salsa20.
Well we already support at least one stream cipher, arc4 with
the cipher interface.
For stream ciphers that have IVs, they can just use the blkcipher
interface. Is there anything else that's required?
Thanks,
--
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