On Thu, 2010-05-27 at 15:53 +0200, Milan Broz wrote: > 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. So would it be better for now to do a --master-key-file /dev/random? Or is this not as secure (as urandom) in this case? > (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.) Uhm... I thought you'd only need to do this once,... and probably not even at system start but then when you do the luksFormat?! So where's the problem? I mean RNG is not required during normal operation, is it? > In some next version I want to make it configurable, > so you can select between /dev/random, /dev/urandom and gcrypt RNG. Ah nice... > (reasons for using urandom was discussed several times here, see archive) Will try to find it... > > 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. Yeah I'm talking about the keyslot passphrase... but is it directly taken (in full lenght) or is it hashed again (and the result used to encrypt the volume key for the slot). > 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. And if master-key is automatically generated,.. cryptsetup always chooses the right lenght!? > > 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? Well,... good question ^^ "As good as possible, aginst NSA&friends"?! ;) For the RNG I'd say I use --master-key-file /dev/random as long as gcrypt support is not possible.. Environment: HDD or SSD that can be (in principle) stolen by anyone. btw: The Hash spec: sha1 from luksDump... how is it used when having aes-xts-plain? Is it at all or is it just a "default-unset-value"? > > 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) So either by setting -s 256 or -s512 respectively > > 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. Of course,... > It is calculated from passphrase > and keyslot blocks using iterated PBKDF2. ... I meant: Are the keyslots only stored in the beginning,.. or like a super block at different places... > There are no duplicate areas, even loss of one bit in keyslot makes it > unusable. ... ok. I see. So one should probably backup it (very securely). > (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.) Well that shouldn't be a problem, is it? I mean if he get's the disk, he'll have it anyway. > > 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. :) Great :) > > 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. Of course,.. but one needs to specify the LUKS device in /etc/crypttab,... which is right now only possible via device, by-uuid, by-path, but not by-label. And I guess this would be a nice feature,.. an consistent with the fact that LUKS is like a filesystem (or container) to many userspace tools. Thanks again, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
