Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-02-09 Thread Mikulas Patocka
On Tue, 9 Feb 2010, Herbert Xu wrote:

 Mikulas Patocka mpato...@redhat.com wrote:
  
  You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
  cipher can't be used to encrypt disks.
 
 No, please see my reply in the previous thread.  What we should
 do is fix arc4.  I just haven't got around to doing it yet.

What is the fix for arc4? Copy the internal state after a key schedule and 
restore it with every encryption?

 As to blacklisting algorithms not suitable for disk encryption,
 that is up to the dm-crypt maintainers to decide.
 
 Cheers,

I think blacklisting arc4 is better, because it provides a fix now. 
Otherwise, people will just keep on arguing what is the clean solution 
and nothing gets done.

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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-02-09 Thread Sebastian Andrzej Siewior
* Herbert Xu | 2010-02-09 18:37:18 [+1100]:

Mikulas Patocka mpato...@redhat.com wrote:
 
 You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
 cipher can't be used to encrypt disks.

No, please see my reply in the previous thread.  What we should
do is fix arc4.  I just haven't got around to doing it yet.

As to blacklisting algorithms not suitable for disk encryption,
that is up to the dm-crypt maintainers to decide.

Herbert, what happend to the check for streamcipher idea you had? Is
it gone? On the other hand it wouldn't be probably that bad to have a
seprate interface to grab a block cipher _or_ a stream cipher. So
something like this wouldn't happen. This is basically the check for
stream cipher without encrypt = decrypt plus with a struct the cra_u
union.
I can't imaging how you want to fix arc4 that it will work in dm-crypt.
The algorithm relies more or less on the fact that it envolves itself
during processing of data.
Salsa works with dm-crypt because the internal state is taken from the
IV and is never written back. dm-crypt always encrypts/decrypts a 512
block in one go. Splitting it in two and requesting two 256 block
encryptions would work with _every_ other block cipher but break salsa.


Cheers,

Sebastian
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-02-09 Thread Herbert Xu
On Tue, Feb 09, 2010 at 09:02:35AM -0500, Mikulas Patocka wrote:
 
 What is the fix for arc4? Copy the internal state after a key schedule and 
 restore it with every encryption?

arc4 should be a blkcipher, not a cipher.  Then it can have an IV
which is where thie should be stored.
 
 I think blacklisting arc4 is better, because it provides a fix now. 
 Otherwise, people will just keep on arguing what is the clean solution 
 and nothing gets done.

The crypto layer makes no guarantee that every algorithm that is
available is suitable for a particular application such as disk
encryption.  FWIW we also export an algorithm called null!

People should not be making uninformed choices on crypto algorithms.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-02-09 Thread Sebastian Andrzej Siewior
* Herbert Xu | 2010-02-10 07:45:19 [+1100]:

 Herbert, what happend to the check for streamcipher idea you had? Is
 it gone? On the other hand it wouldn't be probably that bad to have a

Well again whether that should be done is up to the dm-crypt
maintainers.
Milan liked that afaik.

 seprate interface to grab a block cipher _or_ a stream cipher. So

Just because something isn't a stream cipher doesn't mean that
it is safe for disk encryption.  People simply shouldn't be using
random algorithms for disk encryption.

 I can't imaging how you want to fix arc4 that it will work in dm-crypt.

I thought I've explained this before.  Just turn it into a blkcipher
and add IV.
I beg your pardon. I probably mixed things up.

 The algorithm relies more or less on the fact that it envolves itself
 during processing of data.

This is no different to any stream cipher.
Sure. So we fix arc4 and don't play mother . Okay I will into this :)


Cheers,

Sebastian
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-02-09 Thread Herbert Xu
On Tue, Feb 09, 2010 at 10:12:38PM +0100, Sebastian Andrzej Siewior wrote:

 This is no different to any stream cipher.
 Sure. So we fix arc4 and don't play mother . Okay I will into this :)

That would be awesome.  Thanks!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-02-08 Thread Herbert Xu
Mikulas Patocka mpato...@redhat.com wrote:
 
 You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
 cipher can't be used to encrypt disks.

No, please see my reply in the previous thread.  What we should
do is fix arc4.  I just haven't got around to doing it yet.

As to blacklisting algorithms not suitable for disk encryption,
that is up to the dm-crypt maintainers to decide.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-01-26 Thread Milan Broz
On 01/26/2010 10:22 AM, Sebastian Andrzej Siewior wrote:
 * Milan Broz | 2010-01-25 19:39:11 [+0100]:
 On 01/25/2010 07:29 PM, Mikulas Patocka wrote:
 When using arc4 to encrypt a block device, the resulting device is 
 unreliable. It reads garbage. That's because arc4 is a stream cipher, if 
 you write something, it advances its state and if you attempt to decrypt 
 the same sector, it uses new state that is different.

 This patch disables the use of arc4 on block devices.

 arc4 again. it is simply not a block cipher:-)

 This should be solved inside cryptoAPI and not blacklist it in dm-crypt,
 see that thread
 http://article.gmane.org/gmane.linux.kernel.cryptoapi/3441
 
 I some how remember Herbert saying to test for block size  1. Wouldn't
 this be acceptable to block all stream cipher in one go?

yes, I think it is better.
(...and I just forgot to add that test to dm-crypt after that suggestion.)

Milan
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-01-26 Thread Mikulas Patocka
  This patch disables the use of arc4 on block devices.
 
  arc4 again. it is simply not a block cipher:-)
 
  This should be solved inside cryptoAPI and not blacklist it in dm-crypt,
  see that thread
  http://article.gmane.org/gmane.linux.kernel.cryptoapi/3441
  
  I some how remember Herbert saying to test for block size  1. Wouldn't
  this be acceptable to block all stream cipher in one go?
 
 yes, I think it is better.
 (...and I just forgot to add that test to dm-crypt after that suggestion.)
 
 Milan

Hmm, there is salsa20 that has block size 1, larger initialization 
vectors, and can be used to encrypt disks (although salsa20 doesn't 
currently work with dm-crypt, because it doesn't accept ecb(), cbc(), 
etc. chaining modes --- but if you remove the chaining mode manually, it 
works).

You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
cipher can't be used to encrypt disks.

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


Re: [dm-devel] [PATCH] dm-crypt: disable block encryption with arc4

2010-01-26 Thread Alasdair G Kergon
On Mon, Jan 25, 2010 at 07:39:11PM +0100, Milan Broz wrote:
 This should be solved inside cryptoAPI and not blacklist it in dm-crypt,
 see that thread

Agreed.  I'm not going to apply a dm patch that maintains a hard-coded broken
list.

Alasdair

--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-01-26 Thread Sebastian Andrzej Siewior
* Mikulas Patocka | 2010-01-26 07:27:18 [-0500]:

 yes, I think it is better.
 (...and I just forgot to add that test to dm-crypt after that suggestion.)
 
 Milan

Hmm, there is salsa20 that has block size 1, larger initialization 
vectors, and can be used to encrypt disks (although salsa20 doesn't 
currently work with dm-crypt, because it doesn't accept ecb(), cbc(), 
etc. chaining modes --- but if you remove the chaining mode manually, it 
works).

You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
cipher can't be used to encrypt disks.

Just because it will work does not make it a good idea.

SALSA20 is a stream cipher not a block cipher.
Block ciphers are used to encrypt data.
Stream ciphers are used to create one time pads, a set of encryption
keys, ...
There are block modes like CTR which can turn a block cipher into a
stream cipher. Those should not be used for disk encryption as well.


Mikulas

Sebastian
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-01-26 Thread Mikulas Patocka
On Tue, 26 Jan 2010, Sebastian Andrzej Siewior wrote:

 * Mikulas Patocka | 2010-01-26 07:27:18 [-0500]:
 
  yes, I think it is better.
  (...and I just forgot to add that test to dm-crypt after that suggestion.)
  
  Milan
 
 Hmm, there is salsa20 that has block size 1, larger initialization 
 vectors, and can be used to encrypt disks (although salsa20 doesn't 
 currently work with dm-crypt, because it doesn't accept ecb(), cbc(), 
 etc. chaining modes --- but if you remove the chaining mode manually, it 
 works).
 
 You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a 
 cipher can't be used to encrypt disks.
 
 Just because it will work does not make it a good idea.
 
 SALSA20 is a stream cipher not a block cipher.
 Block ciphers are used to encrypt data.
 Stream ciphers are used to create one time pads, a set of encryption
 keys, ...
 There are block modes like CTR which can turn a block cipher into a
 stream cipher. Those should not be used for disk encryption as well.

Salsa20 is unsuitable for disk encryption in most cases. It would be 
suitable if we knew that the attacker can obtain the image of encrypted 
device at most once --- it is OK to protect against laptop theft (it 
happens just once), but it is not OK to protect against support technician 
spying on your data (he can read them multiple times, if you have multiple 
support requests).

Anyway, what I wanted to say, is that block_size = 1 test is no less 
hacky than !strcmp(cipher, arc4) test.

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


[PATCH] dm-crypt: disable block encryption with arc4

2010-01-25 Thread Mikulas Patocka
Hi

When using arc4 to encrypt a block device, the resulting device is 
unreliable. It reads garbage. That's because arc4 is a stream cipher, if 
you write something, it advances its state and if you attempt to decrypt 
the same sector, it uses new state that is different.

This patch disables the use of arc4 on block devices.

A question to crypto maintainers: Is there some general method how to 
determine that the cipher is a stream cipher, changes its state as it 
progresses and thus is unusable for block devices? I haven't found any 
flag for that.

Mikulas

---

Disable arc4 for encrypting block device

Arc4 is a stream cipher, it's once initialized with a key, it outputs a stream
of bytes (that are xored with the data to be encrypted) and changes it's
internal state.

Because the cipher changes it's internal state, it is not useable for encrypting
block devices --- once someone encrypts a sector of data, the internal state
changes --- and further attempts to decrypt the same block of data use the new
internal state. Thus, the encrypted device returns garbage.

This patch disables the use of arc4 for dm-crypt.

If we wanted to use arc4, we would have to setup the key before encrypting each
sector. That is slow. Because arc4 works by xoring the bitstream with the data,
it is not suitable for encrypting block devices anyway: if the attacker obtains
two images of the same block device at two different times, he can xor them with
each other, eliminating the cipher and getting two xored plaintexts.

Signed-off-by: Mikulas Patocka mpato...@redhat.com

---
 drivers/md/dm-crypt.c |5 +
 1 file changed, 5 insertions(+)

Index: linux-2.6.32-devel/drivers/md/dm-crypt.c
===
--- linux-2.6.32-devel.orig/drivers/md/dm-crypt.c   2010-01-25 
18:55:14.0 +0100
+++ linux-2.6.32-devel/drivers/md/dm-crypt.c2010-01-25 18:57:02.0 
+0100
@@ -1035,6 +1035,11 @@ static int crypt_ctr(struct dm_target *t
goto bad_cipher;
}
 
+   if (!strcmp(cc-cipher, arc4)) {
+   ti-error = Stream cipher arc4 not supported;
+   goto bad_cipher;
+   }
+
if (snprintf(cc-cipher, CRYPTO_MAX_ALG_NAME, %s(%s),
 chainmode, cipher) = CRYPTO_MAX_ALG_NAME) {
ti-error = Chain mode + cipher name is too long;
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-01-25 Thread Milan Broz
On 01/25/2010 07:29 PM, Mikulas Patocka wrote:
 Hi
 
 When using arc4 to encrypt a block device, the resulting device is 
 unreliable. It reads garbage. That's because arc4 is a stream cipher, if 
 you write something, it advances its state and if you attempt to decrypt 
 the same sector, it uses new state that is different.
 
 This patch disables the use of arc4 on block devices.

arc4 again. it is simply not a block cipher:-)

This should be solved inside cryptoAPI and not blacklist it in dm-crypt,
see that thread
http://article.gmane.org/gmane.linux.kernel.cryptoapi/3441

Milan
--
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


Re: [PATCH] dm-crypt: disable block encryption with arc4

2010-01-25 Thread Mikulas Patocka
BTW. I created a script that tests all possible ciphers, keysizes, 
chaining modes and iv modes for dm-crypt. arc4 is the only one that fails. 
You can add it your regression testsuite if you want.

Mikulas#!/bin/sh
dmsetup remove cr0
set -e
cipher=$@
cryptsetup -d key $cipher create cr0 /dev/ram0
mkfs.ext3 -b 1024 /dev/mapper/cr0
fsck.ext2 -fn /dev/mapper/cr0
dmsetup remove cr0
cryptsetup -d key $cipher create cr0 /dev/ram0
fsck.ext2 -fn /dev/mapper/cr0
dmsetup remove cr0
#!/bin/sh
set -e
log
# arc4 - doesn't work
for cipher in aes anubis blowfish camellia cast5 cast6 des des3_ede fcrypt 
khazad seed serpent tnepres tea xtea xeta; do
if [ -n $1 -a $cipher != $1 ]; then
continue
fi
if [ $cipher = aes ]; then
keysizes=128 192 256
blocksize=128
elif [ $cipher = anubis ]; then
keysizes=`seq 128 32 320`
blocksize=128
elif [ $cipher = arc4 ]; then
keysizes=`seq 8 256 2048` 2048
blocksize=1
elif [ $cipher = blowfish ]; then
keysizes=`seq 32 8 448`
blocksize=64
elif [ $cipher = camellia ]; then
keysizes=128 192 256
blocksize=128
elif [ $cipher = cast5 ]; then
keysizes=`seq 40 8 128`
blocksize=64
elif [ $cipher = cast6 ]; then
keysizes=`seq 128 32 256`
blocksize=128
elif [ $cipher = des ]; then
keysizes=64
blocksize=64
elif [ $cipher = des3_ede ]; then
keysizes=192
blocksize=64
elif [ $cipher = fcrypt ]; then
keysizes=64
blocksize=64
elif [ $cipher = khazad ]; then
keysizes=128
blocksize=64
elif [ $cipher = seed ]; then
keysizes=128
blocksize=128
elif [ $cipher = serpent -o $cipher = tnepres ]; then
keysizes=`seq 0 8 256`
blocksize=128
elif [ $cipher = tea -o $cipher = xtea -o $cipher = xeta ]; then
keysizes=128
blocksize=64
elif [ $cipher = twofish ]; then
keysizes=128 192 256
blocksize=128
else
echo UNKNOWN CIPHER
exit 1
fi
for keysize in $keysizes; do
# if ! echo $keysizes | grep -qw $keysize$; then continue; fi
for chaining in cbc ctr ecb lrw pcbc xts; do
chaining_keysize=$keysize
if [ $chaining = xts ]; then
chaining_keysize=`expr $chaining_keysize \* 2 | 
cat`;
if [ $blocksize != 128 ]; then continue; fi
fi
if [ $chaining = lrw ]; then
chaining_keysize=`expr $chaining_keysize + 
$blocksize | cat`
if [ $blocksize != 128 ]; then continue; fi
fi
for iv in null plain benbi essiv:md4 essiv:md5 
essiv:michael_mic essiv:rmd128 essiv:rmd160 essiv:rmd256 essiv:rmd320 
essiv:sha1 essiv:sha224 essiv:sha256 essiv:sha384 essiv:sha512 essiv:tgr128 
essiv:tgr160 essiv:tgr192 essiv:wp256 essiv:wp384 essiv:wp512; do
if [ $chaining = ecb ]  echo $iv | grep -q 
^essiv; then continue; fi
if [ $iv = essiv:md4 ]  ! echo $keysizes | 
grep -qw 128; then continue; fi
if [ $iv = essiv:md5 ]  ! echo $keysizes | 
grep -qw 128; then continue; fi
if [ $iv = essiv:michael_mic ]  ! echo 
$keysizes | grep -qw 64; then continue; fi
if [ $iv = essiv:rmd128 ]  ! echo $keysizes | 
grep -qw 128; then continue; fi
if [ $iv = essiv:rmd160 ]  ! echo $keysizes | 
grep -qw 160; then continue; fi
if [ $iv = essiv:rmd256 ]  ! echo $keysizes | 
grep -qw 256; then continue; fi
if [ $iv = essiv:rmd320 ]  ! echo $keysizes | 
grep -qw 320; then continue; fi
if [ $iv = essiv:sha1 ]  ! echo $keysizes | 
grep -qw 160; then continue; fi
if [ $iv = essiv:sha224 ]  ! echo $keysizes | 
grep -qw 224; then continue; fi
if [ $iv = essiv:sha256 ]  ! echo $keysizes | 
grep -qw 256; then continue; fi
if [ $iv = essiv:sha384 ]  ! echo $keysizes | 
grep -qw 384; then continue; fi
if [ $iv = essiv:sha512 ]  ! echo $keysizes | 
grep -qw 512; then continue; fi
if [ $iv = essiv:tgr128 ]  ! echo $keysizes | 
grep -qw 128; then continue; fi