* [dm-crypt] minimal LUKS container size @ 2011-12-07 11:27 Klaus Schneider 2011-12-07 12:03 ` Milan Broz 0 siblings, 1 reply; 6+ messages in thread From: Klaus Schneider @ 2011-12-07 11:27 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] minimal LUKS container size 2011-12-07 11:27 [dm-crypt] minimal LUKS container size Klaus Schneider @ 2011-12-07 12:03 ` Milan Broz 2011-12-16 7:14 ` Arno Wagner 0 siblings, 1 reply; 6+ messages in thread From: Milan Broz @ 2011-12-07 12:03 UTC (permalink / raw) To: Klaus Schneider; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] minimal LUKS container size 2011-12-07 12:03 ` Milan Broz @ 2011-12-16 7:14 ` Arno Wagner 2011-12-16 8:25 ` Milan Broz 0 siblings, 1 reply; 6+ messages in thread From: Arno Wagner @ 2011-12-16 7:14 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] minimal LUKS container size 2011-12-16 7:14 ` Arno Wagner @ 2011-12-16 8:25 ` Milan Broz 2011-12-16 9:19 ` Arno Wagner 2011-12-19 0:05 ` Arno Wagner 0 siblings, 2 replies; 6+ messages in thread From: Milan Broz @ 2011-12-16 8:25 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] minimal LUKS container size 2011-12-16 8:25 ` Milan Broz @ 2011-12-16 9:19 ` Arno Wagner 2011-12-19 0:05 ` Arno Wagner 1 sibling, 0 replies; 6+ messages in thread From: Arno Wagner @ 2011-12-16 9:19 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] minimal LUKS container size 2011-12-16 8:25 ` Milan Broz 2011-12-16 9:19 ` Arno Wagner @ 2011-12-19 0:05 ` Arno Wagner 1 sibling, 0 replies; 6+ messages in thread From: Arno Wagner @ 2011-12-19 0:05 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-19 0:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-07 11:27 [dm-crypt] minimal LUKS container size Klaus Schneider 2011-12-07 12:03 ` Milan Broz 2011-12-16 7:14 ` Arno Wagner 2011-12-16 8:25 ` Milan Broz 2011-12-16 9:19 ` Arno Wagner 2011-12-19 0:05 ` Arno Wagner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox