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 Clt9QiWI1njA for ; Fri, 16 Dec 2011 10:19:01 +0100 (CET) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 16 Dec 2011 10:19:01 +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 612631404001 for ; Fri, 16 Dec 2011 10:19:01 +0100 (CET) Date: Fri, 16 Dec 2011 10:19:00 +0100 From: Arno Wagner Message-ID: <20111216091900.GA4739@tansi.org> References: <214444323.79200.1323257277449.JavaMail.fmail@mwmweb029> <4EDF560E.9060004@redhat.com> <20111216071410.GA22389@tansi.org> <4EEB0071.7050706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EEB0071.7050706@redhat.com> Subject: Re: [dm-crypt] minimal LUKS container size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Fri, Dec 16, 2011 at 09:25:21AM +0100, Milan Broz wrote: > On 12/16/2011 08:14 AM, Arno Wagner wrote: > > To my surprise, giving alignment --align-payload=1 (or = 2) results > > in a data-area staring at 0x101000, while --align-payload=0 gives > > 2MiB offset. Is this rounded up to multiples of 8? I had a brief > > look into the sources but did not find the relevant code. > > The full behaviour should go into the man-page under the > > explanation for "--align-payload". > > Align 0 should switch to internal default (4k). What about 1? Also 4k? And if I put in, say, 11? > Man page needs rewrite and many grammar and wording fixes... > Any volunteers? :-) > > > Data area size can be 512 bytes (verified with loop-device), but > > not 0 bytes, as this gives an ioctl-error on opening. > > yes, I think there is also internal check now. Possibly. I tested this with the older 1.3.1 > There is a problem with dmcrypt (kernel) -> userspace error reporting, > some fails (like unsupported key size) are only in syslog, > so cryptsetup have to guess to display proper error message, > it need some device-mapper changes though. > > > For cipher, the most extreme I found is RC4 with an 8 bit key. > > This can be luksFormat-ed, but fails on opening. This is > > probably a bug when using arc4, as it fails for 128 bit as well. > > (tested with 1.4.1). > > Repeat after me: arc4 is not a block cipher :-p No need, I know that. But the formatting should fail, not only the opening. And in all fairness, a stream-cipher could still be used for LUKS, just a bit differently and the result would be insecure. > Seriously, you are not the only one trying to do this, > read this thread > http://thread.gmane.org/gmane.linux.kernel.cryptoapi/3822/ > I am not sure if crypto API is changed now though (see Herbert's reply > in that thread.) So there is no way to tell except testing whether a cipher is a stream or block cipher? Not good. Maybe a test should be added, e.g. encrypting a block of test-data twice and if the results are different refuse the format... > > Blowfish with 64 bits works though, but is insecure, so added with > > a warning. > > My strategy is to provide known "secure" defaults and do not block > anything - there can be always use for some old containers. Yes, and that is a good approach. > If anyone feel need for anything else (you can even write your own > kernel cryptoAPI module and use it without changes in dmcrypt), > no problem - but it is user responsibility that the cipher and > parameters are secure enough for his use case. Hence the warning. Arno -- 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 ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier