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
* 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
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
* 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
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~}
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
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
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
* 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
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
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
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
12 matches
Mail list logo
