On Tue, 16 Feb 2010, Herbert Xu wrote:
> On Fri, Feb 12, 2010 at 09:42:28AM +0100, Sebastian Andrzej Siewior wrote:
> >
> > -static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> > +static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
> > {
> > - struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
> > + if (unlikely(!ctx->new_key))
> > + return;
> > + memcpy(iv, &ctx->iv, sizeof(ctx->iv));
> > + ctx->new_key = 0;
>
> Sorry, but this doesn't work.
>
> A ctx is supposed to be reentrant. That is, while one thread
> is working away with a given ctx I should be able to use that
> same ctx in a different thread without them clobbering each
> other.
>
> So that means (in general) you must not modify the ctx in any
> function other than setkey.
>
> This also brings up the bigger question of how we transition to
> this new arc4. I don't think we need to maintain exactly the
> same behaviour as the existing ecb(arc4).
>
> So what we could do is simply add a new blkcipher arc4, alongside
> the existing cipher arc4. Then we can convert the existing users
> across, and finally remove the old arc4.
arc4 can't be used as a block cipher --- see this paper
http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps , it says
that initialization vectors on RC4 are unreliable, if you use (unknown key
concatenated with known IV) or (known IV concatenated with unknown key) as
a RC4 key, the RC4 state can be exposed and the cipher is broken.
If you want to avoid this attack, you'd have to do this for each sector:
- take the secret key and the IV and hash them cryptographically
- use this hash as a RC4 key (to avoid the above related-key attack)
- discard the first 256 bytes from the RC4 output (to avoid another
problem with RC4 --- the beginning of the output is biased)
- use the resulting RC4 state to encrypt a single 512-byte sector
Now, the question is, if RC4 with all this dance around its problems would
be still faster than AES. I doubt.
I think there is not much sense in writing code to allow arc4 to be used
for disk encryption. You should just ban it.
Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
