Milan Broz <mbroz@xxxxxxxxxx> wrote:
> (read from /dev/random can return if there is not enough entropy, it needs
Nope. It blocks.
> On 05/27/2010 04:20 PM, Christoph Anton Mitterer wrote:
>> 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;-)
Hmmmm, yes - but ... well ... :)
Plain cryptsetup without LUKS uses hashing to derive a key from a
pass-phrase but not from a key-file where it takes the data directly as
key. That's why
cryptsetup --key-file=/tmp/key create foo /dev/loop0
and
cryptsetup --key-file=- create foo /dev/loop0 < /tmp/key
are *not* equivalent (in simple terms, you cannot simply write your
pass-phrase to a file and give that to cryptsetup as key-file).
LUKS always uses PBKDF2 to derive the master-key from the key-material.
PBKDF2 is (simplified!) somewhat like a hash function for pass-phrases.
Thus, cryptsetup with LUKS doesn't need to hash a pass-phrase
explicitely and doesn't. That's why
cryptsetup luksOpen --key-file=/tmp/key /dev/loop0 foo
and
cryptsetup luksOpen --key-file=- /dev/loop0 foo < /tmp/key
*are* equivalent (with LUKS you can simply write your pass-phrase to a
file and give that to cryptsetup as key-file).
regards
Mario
--
Good, Fast, Cheap: Pick any two (you can't have all three).
-- RFC 1925, 7a
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
