Hi Herbert, thanks for taking the time to review my patches. My reply is below. On Nov 11, 2007 8:11 PM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html