Re: [dm-crypt] minimal LUKS container size

[Arno Wagner <arno@wagner.name>]

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