[dm-devel] [PATCH] crypto/arc4: convert this stream cipher into a block cipher
Sebastian Andrzej Siewior
sebastian at breakpoint.cc
Mon Feb 22 22:08:35 UTC 2010
* 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?
>Cheers,
Sebastian
More information about the dm-devel
mailing list