[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH] crypto/arc4: convert this stream cipher into a block cipher

* Herbert Xu | 2010-02-22 08:52:17 [+0800]:

>On Mon, Feb 22, 2010 at 08:45:47AM +0800, Herbert Xu wrote:
>> How about this? You extend the IV by one more byte, and use that
>> byte as a boolean flag to indicate whether the IV is valid.  All
So I trick the crypto api to allocate more bytes than ->ivsize says.

>> users that cannot supply their own IVs can then set the IV to zero.
which works fine with kzalloc()

>> When you see the zero flag in the IV, you reinitialise the IV per
>> the key.
Okay. When we have to re-key and the user calls setkey() without
re-allocating thr cipher then I would not notice this. So I need a
counter. And all this will make it work but I still think it is fishy.
Plus we waste 258bytes.

>In fact for arc4 we could just drop the key altogether since it
>plays no part after setting the initial state.
Since I'm not allowed to kfree() the ctx in encrypt() are you proposing
tfm->setup_iv(iv, key)? 

>> > salsa also does not stick to plan here. ctx->input[6-9] is initialized
>> > in encrypt() path. So two threads sharing a ctx are going to clobber
>> > their state.
>> Salsa should also be fixed.
I saw that comming. And I complaind back then that the assembly code was
not pretty enough... and removing the assembly is probably not option :)

>For Salsa on the other hand the key is rather useful since all
>we need is a two-byte IV that's just a sequence number.
No it's 8 bytes. Berstein's U8TO32_LITTLE() is actually a cpu_to_be32().
Not sure if he knows it :)
However I'm not sure where you going with this. salsa is fine besides
the clobber thing, isn't it?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]