On Tue, Mar 13, 2012 at 06:49:25PM +0100, Javier Juan Mart?nez Cabez?n wrote: > > > > 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)? Yes, as I wrote before. But you can never be sure. > 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. Ah, no. You decrypt the data and look whether it looks like something non-random. > 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. You could try to mount. But there are still scenarios where you could do damage. That is the reason why, e.g. Knoppix mounts all detected filesystems read-only, just to be sure. Only the user can know what is right and can be mounted r/w. That is why there is /etc/fstab. Arno > 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 > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
