On 05/27/2010 02:51 PM, Christoph Anton Mitterer wrote: > 1) With LUKS there's a master key (the one which is decrypted via the > key-slot-keys and that's actually used to decrypt the payload data). > How is it generated? Via /dev/random or /dev/urandom? Currently LUKS master (aka volume) key is generated using /dev/urandom if not provided in --master-key-file (see below), I want to add more options for RNG soon. (My plan was to switch to gcrypt RNG by default but it is not possible, see https://bugs.g10code.com/gnupg/issue1217 - it is unusable for default cryptsetup key generator use.) In some next version I want to make it configurable, so you can select between /dev/random, /dev/urandom and gcrypt RNG. (reasons for using urandom was discussed several times here, see archive) > 2) They key-files specified via --key-file when creating LUKS volume > or adding a new key... is it directly used as the > master-key-encrypting key or is it somehow hashed and the result is > used for the actual encryption? No. --key-file is always keyslot passphrase (for LUKS), if you want to specify master key, you have to use cryptsetup 1.1.x and --master-key-file. If not specified, RNG is used to generate master key. (For plain create it is hashed, but it is not question here.) > And as a follow-up,.. does it need to have a special size, related to > the used cipher/mode, or can it be e.g. 1 MB and is simply hashed? Passphrase length (key to unlock keyslot) from key-file is unlimited, master-key-file (if used) is directly used as key so it is limited by algorithm/key size. > 3) Which cipher/mode is the "most secure" one? Perhaps with the > restriction that AES should be used? > Currently I always use aes-xts-plain. > AFAIK lrw is "borken" or has at least some design issues which is why > xts was developed, right? > Or is something different better? Secure against whom? Secure in which environment, with which RNG? ... > Should one use plain with xts or better essiv or even benbi? From what > I understood how XTS works is, that plain should be just fine and > essiv/benbi should give no additional security, right? yes. (simplifying) XTS mode basically splits key into two parts, one part is used for generating IV using AES, ESSIV is not needed here. (and note benbi is just plain IV generator in principle, only endianess differ) > I guess "best" is to use AES with 256 bits, right? How large has the > key to be then? I've read somewhere that one needs actually 512 bits > then for use with XTS. Because of the key split, for XTS mode you must use 256 bit or 512 bits key. (So internally it will use AES128 or AES256) > 4) Is the master key only stored at one place on the disk, or at multiple? > Imagine I have some severe disk errors, and the LUKS header is > completely lost... is the dump as created by luksHeaderBackup enough > the get decryption working again? Master key itself is not stored anywhere. It is calculated from passphrase and keyslot blocks using iterated PBKDF2. There are no duplicate areas, even loss of one bit in keyslot makes it unusable. Using luksHeaderBackup (with passphrase knowledge) is enough to recover it. (In fact it is just plain snapshot of header and kesylots. So anyone with only header backup and passphrase knowledge can decrypt the disk later.) > 5) I guess it's still true that one should (for security reasons) fill > the disk with random data before creating the LUKS volume, right? > I guess this is also true, when using SSDs, at least when not using TRIM? yes. and TRIM is not yet supported anyway in kernel DM (including dm-crypt). All devices in stack must support it to work it reliably, it is similar to topology alignment support - it must propagate through stack of devices properly. > May I suggest that you add a feature to cryptsetup, that when doing a > luksFormat, the disk is automatically filled with random data, and an > additional switch to disable it (I guess the default should be to do > the filling, although it's time consuming... I mean we do the whole > crpyt-thingy for our paranoia ;) ). yes, I want to add this, somehow, someday. :) > 6) Are there plans to at LABEL soupport to the LUKS volumes? I mean > UUID is already there... No plans. Label is usually used together with FS, so after unlocking the disk you can use label on FS on top of that. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
