On Sun, Jan 24, 2010 at 11:50:26AM +0100, Milan Broz wrote: > On 01/24/2010 07:17 AM, Roscoe wrote: > > Has there been much consideration as to this matter within OS > > installers? Does anyone suspect any latent issues? > > > > If we take a Debian text installs with no network, that removes NIC > > generated interrupts and the mouse as sources of entropy, and > > considering setting up partitions [and consequently LUKS/LVM/RAID] is > > one of the first things you do within the installer, I start to become > > a bit suspicious of the quality of the 512 MK bits pulled for > > AES-256-XTS. > > Yes, this is interesting problem, just adding some notes: > (please correct me if I am wrong in some points) > > - cryptsetup uses /dev/urandom, so volume key quality really depends on > RNG here, exactly the same like all other key generation during install That is probably a design mistake. It should use /dev/random and have people wait for enough entropy. The man page for random/urandom (Debian: just use "man urandom") explicitely suggests this: "As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys." ^^^^^^ LUKS keys are also long-lived and should therefore not come from /dev/urandom. I propose to fix this by making /dev/random the default, and maybe have use of /dev/urandom as commandline option with a strong warning. It may be necessary to ask people to enter some keystrokes during key generation with /dev/random, otherwise key generation may block forever in the minimal environmental entropy scenario. On the other hand, entropy cannot be generated out of thin air, so such a request is entirely reasonable. This needs to be mentioned in the documentation and the --help online help. I am convinced that it is better to block in an entropy starved situation than to start producing bad keys. > - cryptsetup/libcryptsetup supports now --master-key-file, you can use your own > pre-generated volume (master) key if you wish. > (Another reason was ability to reformat LUKS header with only MK knowledge) > > (Side note about plain (non-LUKS) mode with random key: if initscripts forgot > to re-seed RNG, various low-entropy attacks are possible during system boot. > Encrypted swap is usually initialised before network and other source of entropy are started! > Initscript must initialise plain encrypted device in two steps - first fs where is > the RNG seed stored, reseed RNG, and then format encrypted devices using random key.) > > (and in fact, cryptsetup cannot do any statistical tests for RNG, input is too small, > so it must trust kernel here IMHO) > > - maybe someone should also describe RNG when system is in FIPS140 mode then > (RNG initialisation and approved RNG are exactly defined, IIRC RNG must not > produce any output if not properly seeded etc.) Use of /dev/random instead of /dev/urandom should ensure that. > - maybe distribution can run some RNG tests also in installer > before generating key? > (I mean e.g. rngtest from rng-tools, > or http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html > or http://www.phy.duke.edu/~rgb/General/dieharder.php > and from this "verified" source pre-generate MK for cryptsetup luksFormat...) That would not work. The randomness properties of /dev/urandom are good with regard to these tests. The tests do not cover initialization quality, unless you start to compere different initializations. Even then you would need two times exactly the same initialization to notice something was wrong. The problem here is that these tests look for bad distributions of the output, while while crypto is not so much concerned with good distribution, but critically depends on predictability. In order to judge the initialization data quality for a crypto PRNG, you have to look at the initialization data directly or break the used crypto-hash to a degree that you can easily reverse it. That is typically completely infeasible and the statistical tests for PRNGs can certainly no do it. However /dev/random does this itself by estimatinh how much entropy it has gathered and not ginving you anything until it has a significant pool. It will then only deplete part of the pool before waiting for more entropy. Here is a small test you can do to see this in action (no network load, or it will probably not work): cat /dev/random | hd On my machine that gives me 512 bytes of randomness and then stops until I move the mouse or type something. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
