From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoNlEy6YSEJ6 for ; Tue, 13 Mar 2012 15:56:34 +0100 (CET) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 13 Mar 2012 15:56:34 +0100 (CET) Received: from gatewagner.dyndns.org (84-74-163-71.dclient.hispeed.ch [84.74.163.71]) by v4.tansi.org (Postfix) with ESMTPA id E14FE205346 for ; Tue, 13 Mar 2012 15:56:33 +0100 (CET) Date: Tue, 13 Mar 2012 15:56:33 +0100 From: Arno Wagner Message-ID: <20120313145633.GA16934@tansi.org> References: <4F5E7A6B.2090207@redhat.com> <2451c2f8f9dec229cee7eadb6dd82207.squirrel@ssl.verfeiert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2451c2f8f9dec229cee7eadb6dd82207.squirrel@ssl.verfeiert.org> Subject: Re: [dm-crypt] blkid and aes-cbc-plain/aes-cbc-essiv:sha256 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de In fact it is impossible to distinguish ciphers except by looking whether the decrypted contents makes sense. On the other hand, looking for structire in the decrypted data works well, but to distinguish mode in addition to cipher, you have to look at more than just one cipher block. Ideally look at the whole sector. Now, if you know what filesystem is supposed to be in there, you can try to recognize its first block. Or you can to a (sample) entropy analysis for a the whole first block decrypted. That would identify the mode quite reliably if (and only if) the first block is ensured to have relatively low entropy in decrypted state. That said, I agree that guessing is not the right approach. What if, for example, there is an old first block lying around, but the new crypto-container is at an offset? In that case not even the cipher or the key might be the same! Arno On Tue, Mar 13, 2012 at 03:46:40PM +0100, Sven Eschenberg wrote: > What Milan said is this: > > It is impossible to distinguish between ESSIV and non ESSIV modes. The > only means of knowing which is right is when the read data seems to be > plausible. > > But that's the very problem: what do you consider plausible? > > Here's an example, plain and ESSIV look the same (at the relevant area on > disk) and thus a FS signature is found, the FS driver tries to mount the > FS and then detects, that the rest of the FS structures seem to be broken. > It fails. Or it might aswell try to recover the FS and by doing so corrupt > the data irreversibly. > > This becomes even more problematic, if the Volume does not host a FS but > something else. > > Thus the only sane approach is, to not do any 'educated' guessing, since > it might work in some (or even many) cases, but corrupts significant > amounts of data, when it fails. > > (I chose educated guessing, since auto-detection implies that you can make > sure your detection result is valid) > > Regards > > -Sven > > > > On Tue, March 13, 2012 02:03, .. ink .. wrote: > > Thanks for your quick response, > > > > > >> 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. > >> > > > > > >> > >>> My suggestion is to ignore "aes-cbc-plain" and just use current default > >> (and give user option to overwrite it manually). > >> > >> Milan > >> > > > > My tool is meant to be simple, that means the user provides only a path to > > encrypted volume and a passphrase .All other options are default and hard > > coded and a user can not change them.If a user want to use non default > > option then the tool is too simple for them as it will lead to unnecessary > > complexity. > > > > Below is what happen when a user provides a path to an encrypted volume > > and > > a passphrase to open a volume > > > > 1. The volume is checked to see if its luks or not. If it is, it is then > > opened as luks with luks default as they are 1.4.1. > > > > 2. If a volume is not luks, it is then assumed to be plain and the first > > attempt is to open it with plain defaults as they are in 1.4.1. If that > > fail, it is then opened as plain with default values are they were in > > 1.3.0 > > > > I do not see any danger with the current design of supporting both plain > > modes as long as,as it currently appear to be, mount can distinguish the > > two. The advise to drop "legacy mode" will make sense if the mount > > failure > > is not a guaranteed way to distinguish the two(.it seem to be working so > > far with vfat, ext3/4 file systems). Is this what you are saying? > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 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