I have not enough knowledge about cryptographic questions and maybe this
could be and idiot suggestion from an heretic in this kinds of
questions, but could not be something like bruteforcing tools works (but
reversed)?
They ciphered (one way hashes) what it thinks is the key and then
compare it with the hash present if its the same then this is the key.
Is not feasible to read the first X data (enough to take the superblock)
from the ciphered harddisk and then test the key and options taken from
the user and in the result search for example a superblock. With this
since you don't work with the true harddisk you can't corrupt data, and
would be propably faster.
So, somethink like this: -dd bs=whatever count=whatever
if=/dev/ciphereddisk of=testing
-cryptsetup whatever testing
-now look for structures:
if filesystem structures then validkey/options
else error
On 12/03/12 23:36, Milan Broz wrote:
> 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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
