Stelios Bounanos wrote:
> I was surprised to see arc4 perform so badly, particularly since
> "openssl speed" results tell a very different story. I decided to do
> some simple benchmarking of my own but I can't seem to get cryptsetup to
> work with arc4:
>
> # cryptsetup luksFormat --align-payload=512 -q -c arc4 /dev/sda4 key
> # cryptsetup luksOpen -d key /dev/sda4 ctest
> Command failed: No key available with this passphrase.
>
> The above commands work fine with aes. I can see arc4 in /proc/crypto.
>
> Any ideas?
There is apparently some problem in kernel, not sure if dm-crypt or crypto
api one, This ARC4 configuration is allowed (no errors) but produces something
more like random generator:-)
one sector device:
# dmsetup create x --table "0 1 crypt arc4-cbc-plain 0123456789abcdef 0 /dev/sdb 0"
# sha256sum /dev/mapper/x
d37afeeb57a60b69715edd99f2a1523e77f6be51a1c61c56efc91ed691c90dfc /dev/mapper/x
# sha256sum /dev/mapper/x
fdc87e8e9f158d26e58c5b48c80375b56cc24d0c088872f4aacc7e19fb5c5599 /dev/mapper/x
Not sure what's wrong yet...
Milan
--
[email protected]
* Milan Broz | 2009-08-05 15:09:59 [+0200]:
>There is apparently some problem in kernel, not sure if dm-crypt or crypto
>api one, This ARC4 configuration is allowed (no errors) but produces something
>more like random generator:-)
>
>one sector device:
># dmsetup create x --table "0 1 crypt arc4-cbc-plain 0123456789abcdef 0 /dev/sdb 0"
>
># sha256sum /dev/mapper/x
>d37afeeb57a60b69715edd99f2a1523e77f6be51a1c61c56efc91ed691c90dfc /dev/mapper/x
>
># sha256sum /dev/mapper/x
>fdc87e8e9f158d26e58c5b48c80375b56cc24d0c088872f4aacc7e19fb5c5599 /dev/mapper/x
>
>Not sure what's wrong yet...
If you close the mapping, re-run the test you should get the same
result. There is nothing wrong :)
Don't use this as a block cipher in dm-crypt, it is a bad idea.
The long story:
ARC4 is a stream cipher and not a block cipher. Its internal state is
reseted in setkey() and every crypto request (encrypt/decrypt don't
matter) update the internal state of the stream cipher. That's why you
get a different result every time you read the same block.
If you want to use this stream cipher in dm-crypt you would have to
setup it up in ECB mode and use a key like "passphrase-IV". You have to
set this key before a requests and wait until its done until you
issue another crypto request (which includes setkey).
CBC will not work because one of its requirements is that the cipher
provides an inverse function which ARC4 simply does not have.
In generall your problem here is that you want to encrypt/decrypt blocks
(seeks) and not a stream.
>Milan
Sebastian
Sebastian Andrzej Siewior wrote:
> Don't use this as a block cipher in dm-crypt, it is a bad idea.
>
> The long story:
> ARC4 is a stream cipher and not a block cipher. Its internal state is
> reseted in setkey() and every crypto request (encrypt/decrypt don't
> matter) update the internal state of the stream cipher. That's why you
> get a different result every time you read the same block.
>
> If you want to use this stream cipher in dm-crypt you would have to
> setup it up in ECB mode and use a key like "passphrase-IV". You have to
> set this key before a requests and wait until its done until you
> issue another crypto request (which includes setkey).
yes, I understand why this happens. I do not want to use stream cipher,
but apparently users will do that:-)
My question was why crypto allows this setting?
Or maybe what to do in dm-crypt to not allow user set such cipher
mapping (because it cannot produce anything useful).
IMHO it will not work even in ECB mode here for dm-crypt.
(also dm-crypt uses own IV function generators, but it is another story)
> CBC will not work because one of its requirements is that the cipher
> provides an inverse function which ARC4 simply does not have.
Again, why crypto API allows to use it and do not produce error then?
Milan
--
[email protected]
* Milan Broz | 2009-08-06 09:46:59 [+0200]:
>yes, I understand why this happens. I do not want to use stream cipher,
>but apparently users will do that:-)
So once they discover that they have salsa20 in kernel they see another
problem.
>My question was why crypto allows this setting?
Well, WLAN is afaik the only user and they use it that way. So it
is okay as long as you now what you do :)
>Or maybe what to do in dm-crypt to not allow user set such cipher
>mapping (because it cannot produce anything useful).
You could encrypt one block twice and compare the result. This sounds
like a dirty hack.
>IMHO it will not work even in ECB mode here for dm-crypt.
You could make it work but it is not worth it.
>> CBC will not work because one of its requirements is that the cipher
>> provides an inverse function which ARC4 simply does not have.
>
>Again, why crypto API allows to use it and do not produce error then?
WLAN folks are the only user of arc4 afaik and they probably hacked it
quick together. Since stream cipher don't provide an inverse function it
is an abuse of the API because encrypt/decrypt don't do what one would
expect.
Herbert, any concern to inroduce
#define CRYPTO_ALG_TYPE_STREAM_CIPHER 0x00000007
and split block cipher from stream cipher?
So no one would mix them up since dm-crypt for instance will look just
for block ciphers. Unless you prefer that the user knows what he is
doing :)
>Milan
Sebastian
On Thu, Aug 06, 2009 at 10:38:05AM +0200, Sebastian Andrzej Siewior wrote:
>
> Herbert, any concern to inroduce
> #define CRYPTO_ALG_TYPE_STREAM_CIPHER 0x00000007
> and split block cipher from stream cipher?
> So no one would mix them up since dm-crypt for instance will look just
> for block ciphers. Unless you prefer that the user knows what he is
> doing :)
Stream ciphers should all have block size 1 so you can just check
on that.
In any case, I agree that we should make it extremely difficult
for users to select an insecure configuration.
Cheers,
--
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
Sebastian Andrzej Siewior <[email protected]> wrote:
>
> The long story:
> ARC4 is a stream cipher and not a block cipher. Its internal state is
> reseted in setkey() and every crypto request (encrypt/decrypt don't
> matter) update the internal state of the stream cipher. That's why you
> get a different result every time you read the same block.
Actually I think that's a bug. These ciphers really should not
modify their tfm state between operations. Requiring a setkey
before each new operation precludes parallel processing.
I noticed that salsa seems to be broken in the same way, but at
least it should be easy to fix.
arc4 on the other hand needs to be converted to a blkcipher.
Cheers,
--
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
On Sat, Aug 08, 2009 at 01:08:32PM +1000, Herbert Xu wrote:
>
> I noticed that salsa seems to be broken in the same way, but at
> least it should be easy to fix.
>
> arc4 on the other hand needs to be converted to a blkcipher.
In fact the internal state shouldn't be kept in the tfm at all.
I'll change it into an IV in order to allow continuation.
Cheers,
--
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