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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
