[dm-crypt] Entropy available for luksFormat during GNU/Linux installs

Arno Wagner arno at wagner.name
Sun Jan 24 14:11:01 CET 2010


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 


More information about the dm-crypt mailing list