On 05/28/2010 12:56 PM, Christoph Anton Mitterer wrote: > On Thu, 2010-05-27 at 16:45 +0200, Milan Broz wrote: >>> 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. master-key-file is new option which allows using pre-generated master key. Please use it only if you must - it was designed for Key Escrow functions, (which uses libcryptsetup directly anyway) not for normal use. >> >> (read from /dev/random can return if there is not enough entropy, it needs >> implement some more code to use.) > Is it then secure (an better than using /dev/urandom) to do something > like: > > mount -t tmpfs foo /mnt > cd /mnt > dd if=/dev/random of=mk bs=1 count=64 > cryptsetup --master-key-file mk -s 512 -c aes-xts-plain --key-file > someKeyFile luksFormat /dev/blafasl > > ? > The master key should not be leaked to disk,... it 64 bytes large, and a > keyfile is used to encrypt it. > > Or better stick with urandom? See above, do not use it at all just run luksFormat in your case which generate key from /dev/urandom. >> 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) > Can/should I change it to something "better" (e.g. SHA512)? > I guess this could be done by simply exchanging the key slots and I do > not have to reencrypt the whole disk? First read archive discussion about that - there is no problem with SHA1 in this use. You can define hash during luksFormat (-h <alg>) with cryptsetup 1.1.x, but if you select somethin other than sha1, it will be incompatible with old distros. You cannot change it later (only by reformatting header). Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt