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 at wagner.name
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