Hello Milan, hey Christoph,
Thanks Milan for the explanation why the ext3 filesystem is detected
even with a different initalization vector.
To be honest, I cannot do anything about the bugreport, but again and
again suggest to set the used cipher, hash and keysize for plain
dm-crypt devices in
Hey Christoph, hey Milan,
On 08/02/2011 Christoph Schindler wrote:
This all could be entirely my fault, of course, but I always just did it
the default way.
Here is the table with the old (correct) cipher:
pvsvie0401_1-cbackup_1: 0 3907018752 linear 8:17 384
backup_1: 0
On 02/13/2011 02:10 PM, Jonas Meurer wrote:
I'm able to reproduce this bug. Not sure what to do about it though. It
seems like aes-cbc-plain and aes-cbc-essiv:sha256 give similar results
for the bytes where ext filesystems store the filesystem header/stamp.
Well, I think it is expected...
-
Package: cryptsetup
Version: 2:1.1.3-4
Severity: minor
With the upgrade to squeeze, the default cipher for crypt devices
changed, but cryptdisks_start still accepts the (wronly decrypted)
device as containing an ext3 filesystem.
This happens at least when using the current default cipher to
On 02/08/2011 03:40 PM, Christoph Schindler wrote:
Package: cryptsetup
Version: 2:1.1.3-4
Severity: minor
With the upgrade to squeeze, the default cipher for crypt devices
changed, but cryptdisks_start still accepts the (wronly decrypted)
device as containing an ext3 filesystem.
Out of
This all could be entirely my fault, of course, but I always just did it
the default way.
Here is the table with the old (correct) cipher:
pvsvie0401_1-cbackup_1: 0 3907018752 linear 8:17 384
backup_1: 0 3907018752 crypt aes-cbc-plain
6 matches
Mail list logo
