[dm-crypt] minimal LUKS container size

[dm-crypt] minimal LUKS container size

[Klaus Schneider]

Hello

thanks for the effort you put into developing LUKS and cryptsetup. I have a suggestion for improving the package: Please document the minimal size for a LUKS container; I could not find it in the documentation nor in the FAQ. It would also be helpful if "cryptsetup luksCreate" would fail with an error message if the container is too small. Currently, "cryptsetup luksCreate" succeeds and "cryptsetup luksOpen" fails with a device-mapper error, which does not point the user into the right direction. It took me quite some time to find out the reason being too small a container. As far as I could find out by trial and error, for cryptsetup 1.3 with the default settings the container must be larger than 2MB (creating a 3MB container results in a 1MB filesystem), whereas for the old 1.1 release it seems to be > 1MB. Is this correct?
Rational for a small container: I want to have a key file on a USB medium secured in a LUKS container. Since the key is only 512 Bit long, a very small container would be sufficient.

Thank you very much.

Regards,
Klaus

___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: [dm-crypt] minimal LUKS container size

[Milan Broz]

On 12/07/2011 12:27 PM, Klaus Schneider wrote:
> Hello
> 
> thanks for the effort you put into developing LUKS and cryptsetup. I
> have a suggestion for improving the package: Please document the
> minimal size for a LUKS container; I could not find it in the
> documentation nor in the FAQ. It would also be helpful if "cryptsetup
> luksCreate" would fail with an error message if the container is too
> small. Currently, "cryptsetup luksCreate" succeeds and "cryptsetup
> luksOpen" fails with a device-mapper error, which does not point the
> user into the right direction. It took me quite some time to find out
> the reason being too small a container. As far as I could find out by
> trial and error, for cryptsetup 1.3 with the default settings the
> container must be larger than 2MB (creating a 3MB container results
> in a 1MB filesystem), whereas for the old 1.1 release it seems to be
> > 1MB. Is this correct? Rational for a small container: I want to
> have a key file on a USB medium secured in a LUKS container. Since
> the key is only 512 Bit long, a very small container would be
> sufficient.

Minimal size depends on two things:
 - volume key size
 - alignment of data area

Cryptsetup 1.3 by default aligns data to 1MB offset multiple, that's why
you see this change.

You can switch to old alignment by using data alignment override, e.g.

cryptsetup luksFormat -s 128 --align-payload=8

(So here forcing keysize to 128bit and forcing alignment to 4k offset.
- vaule is in 512 byte sectors.
This is perhaps the smallest header possible while still using
reasonable key size - 1032 x 512 bytes sectors ~ 520kB)

(But also note that misalignment to flash memory block can have
some performance effects.)

Anyway, some example in FAQ would be nice.

Milan

Re: [dm-crypt] minimal LUKS container size

[Arno Wagner]

On Wed, Dec 07, 2011 at 01:03:26PM +0100, Milan Broz wrote:
> Minimal size depends on two things:
>  - volume key size
>  - alignment of data area
> 
> Cryptsetup 1.3 by default aligns data to 1MB offset multiple, that's why
> you see this change.
> 
> You can switch to old alignment by using data alignment override, e.g.
> 
> cryptsetup luksFormat -s 128 --align-payload=8
> 
> (So here forcing keysize to 128bit and forcing alignment to 4k offset.
> - vaule is in 512 byte sectors.
> This is perhaps the smallest header possible while still using
> reasonable key size - 1032 x 512 bytes sectors ~ 520kB)
> 
> (But also note that misalignment to flash memory block can have
> some performance effects.)
> 
> Anyway, some example in FAQ would be nice.

Just added this. Tested with 1.3.1 and also 1.4.1 for arc4.

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

Data area size can be 512 bytes (verified with loop-device), but
not 0 bytes, as this gives an ioctl-error on opening.

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

Blowfish with 64 bits works though, but is insecure, so added with
a 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 

Re: [dm-crypt] minimal LUKS container size

[Milan Broz]

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

Re: [dm-crypt] minimal LUKS container size

[Arno Wagner]

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 

Re: [dm-crypt] minimal LUKS container size

[Arno Wagner]

On Fri, Dec 16, 2011 at 09:25:21AM +0100, Milan Broz wrote:
> Man page needs rewrite and many grammar and wording fixes...
> Any volunteers? :-)

I can do that, but I expect it will be late January before I 
find the time. And I may have a number of questions.

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