Re: [dm-crypt] minimal LUKS container size

[Milan Broz <mbroz@redhat.com>]

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).

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.

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

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.)

> 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.

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.

Milan