On 05/27/2010 04:20 PM, Christoph Anton Mitterer wrote: > 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? --master-key-file intentionally can read only regular file. (read from /dev/random can return if there is not enough entropy, it needs implement some more code to use.) > >> (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?! Sure. The problem is in automated installations which calls luksFormat. Switching to gcrypt RNG make them unusable (gathering 300 bytes of real entropy just to initialize RNG can take hours in this environment. Of course reading urandom can be another problem here.) That's why I want to make it configurable - if you want use it, it will ask you to generate some entropy by moving mouse etc. >>> 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). Read man page - notes on password processing and LUKS documentation, both is described there;-) >> 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!? master key length is defined by used algorithm (and -s switch and compiled-in defaults) > 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"? This is LUKS (keyslot) hash algorithm used (together with PBKDF2) when unlocking keyslot. (see documentation again, project site http://code.google.com/p/cryptsetup/ -> Specification) >>> 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... In the beginning only (see luksDump, payload offset in sectors - everything before that offset is LUKS, after is encrypted data area) >> (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. With old backup, he can decrypt disk even with already deleted/changed keyslot passphrase. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
