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. > > (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? > Sure. The problem is in automated installations which calls luksFormat. Are automated installations really a target audience for cryptsetup? Either the keyfile/passphrase has to be automatically copied during installation (which sounds after insecurities to me) or manual user input (passphrase) is required anyway... And I'd suggest, even for automated installations one should per default use a blocking /dev/urandom or libgcrypt... and only manually via command line switch, the change to urandom should be possible (not automatically after e.g. 4 mins blocking) > 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. Sounds nice :) > > 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) 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? > >> (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. Of course,.. but that's always the case,... whether I've backuped the header or not.... once an attacker was able to copy the material,.. he'll be able to access it as soon as the algo is weak/broken. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
