On 03/12/2012 10:30 PM, .. ink .. wrote:
when a plain volume is created with "aes-cbc-plain" and opened with "aes-cbc-essiv:sha256", the blkid program correctly reads the file system of the volume but mount command fails to mount it. Is this behavior expected behavior?
You have the same cipher (AES) and key, and the same CBC mode. The only difference is IV generator. So in reality it means, that only first block (16 bytes) on plaintext disk will differ. (See how CBC mode operates.) Of course that mount will fail. But unfortunately, blkid uses signature to detect filesystem, which is still clearly visible.
I am the developer of zulucrypt, the frontend to cryptsetup and i support both by first trying to open the volume with "aes-cbc-essiv:sha256" and then with "aes-cbc-plain" if the former fail.This allows the tool to seamlessly open "old" plain volumes in legacy mode
For plain mode, user must provide the cipher, mode and keysize. Please do not invent autodetection - you just proved it will lead to data corruption. This is one of the reasons why LUKS was invented, where cipher and mode is stored in metadata.
The above works but the mount system call adds ugly looking logs to /var/syslog when it fails to mount the volume the first time around i am trying to see if i can get around this. It would have been great if blkid would fail to read the file system to tell me the plain volume is opened in wrong mode but it reads it correctly leaving it up to mount command to notice the wrong mode and then fail to mount and add the ugly looking log entry.
Blkid has nothing to do with that. Imagine this situation: overwrite every first 16 bytes of every sector on disk and it will still detect ext3/4 - because signature is located elsewhere. (If we fix ext4 detection - not sure if it even possible - the problem reappears on different format.)
can i use any cryptsetup API to distinguish volumes created with those two cyphers?
Not for plain mode. There is no way how to check it automatically. You can find way for one specific case but not a generic rule. (What if plaintext disk is just random data?) My suggestion is to ignore "aes-cbc-plain" and just use current default (and give user option to overwrite it manually). Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
