[PATCH] Require minimum random data entropy when creating LUKS (#1073679)

Vratislav Podzimek vpodzime at redhat.com
Sun Aug 31 20:37:11 UTC 2014


On Fri, 2014-08-29 at 17:03 -0400, Chris Lumens wrote:
> > Creating new LUKS format requires high-quality random data and such quality may
> > be specified by minimum entropy of kernel's random data pool required. We can
> > tell blivet what should be the minimum entropy available when creating LUKS and
> > we can provide callbacks which inform users about what's happening and how they
> > can help to increase the available entropy.
> 
> From the UI side, we have tried to avoid popups where possible.  I'm not
> concerned about the expertness of asking for entropy given that this is
> an opt-in thing that people who choose to encrypt will see (and
> hopefully they have some idea what entropy means), though perhaps the
> wording can be tweaked a little bit.
The wording can definitely be tweaked to make it better understandable
to people who don't know much about encryption and entropy. Maybe
something like "The system needs better quality of random data, you can
improve it by typing on keyboard and moving your mouse"?

> 
> What I'm more curious about is:  Will we only know there's not enough
> entropy when we go to do the encryption, or will we know beforehand?
> Would we know at the time the user is entering their passphrase, in
> order to combine that task with collecting entropy?  If so, we can avoid
> having to do a popup.  If not, I'll have to think about it a little
> more.
That would be nice, but the problem is that the entropy has to be
checked and gathered right before the luksFormat happens because
otherwise it may fail significantly in the meantime. Kernel gathers
entropy up to 4096 bits, but nothing more. And every fork consumes quite
a lot of entropy due to randomized placement of the process' VM into
physical memory. The graph showing the captured data for my school
project [1] shows how entropy rises and drops during the installation
process. The first big drop is  partitioning (we run a lot of binaries)
then there's only a little entropy during package installation probably
because of RPM scriplets, etc.

[1] https://vpodzime.fedorapeople.org/entropy_graph.png

The only solution that comes to my mind is gathering entropy, reading
random data and storing them aside, and then giving it back to kernel as
an entropy pool right before we create the new LUKS format. However,
that would be quite a lot of not so nice (probably C) code and we would
need to figure out how much entropy each LUKS creation eats so that we
can gather enough entropy in advance.

Hard to tell, but when debugging the patches, I had to set the minimum
entropy requirement to 1024 bits (which is insanely much) because the
system had ~800 bits on its own. So with a sensible limit like 256 bits
the popup should hardly ever appear. A different situation comes with
kickstart installations which have significantly less (ks + text mode
had something around 200 bits), but the system gets from low amount of
entropy to something around 500 bits quite fast on its own.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list