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

Vratislav Podzimek vpodzime at redhat.com
Thu Sep 11 09:13:53 UTC 2014

On Tue, 2014-09-09 at 09:36 -0400, Anne Mulhern wrote:
> > > I believe I read that there is a problem with remote actions
> > > to increase entropy. If the install is being controlled from a remote
> > > keyboard, then the wiggles of the user at that keyboard are de-randomized
> > > by transmission to the remote location, and therefore don't increase the
> > > entropy.
> > Well, generating network traffic is another good way to increase
> > entropy, so I believe typing something on a keyboard even over a remote
> > access should help.
> Well, I can't remember where I saw the article, if I turn it up again I'll
> let you know.
> > 
> > > 
> > > If entropy is less than min entropy does TUI hang forever? It looks like
> > > it.
> > > Should these users instead be given some way to escape? It seems like there
> > > is nothing to guarantee or even make likely that entropy will increase up
> > > to
> > > the minimum.
> > Users can always escape by terminating the installation. Again, I have
> > to point out that there shouldn't be any problems with a reasonable
> > value of minimum required entropy (like 256 bits).
> >
> Is it an accessibility issue? If they can only type very slowly could
> there be a problem? Or would entropy inexorably rise even if slowly?
I'm sure we have much bigger accessibility issues in other places we
should start with if we want to care about accessibility.

> > > 
> > > Also, is it really necessary to show the user the percent of required
> > > entropy in TUI once
> > > enough is reached? It's hard for me to imagine that that's a point at which
> > > they care
> > > much.
> > You mean like leaving it to [93 %] and then hang for a while before
> > buffer is read and LUKS is created? That doesn't seem like a good idea
> > to me. The final value >= 100 % is intentionally printed to give users
> > the information that we have enough and they should stop typing and that
> > things start to move on again.
> I guess there might be confusion. I thought that the code
> already prints "Done" immediately after the line we're discussing,
> so there is not currently any danger of the hanging and waiting behaviour
> you're describing if that line is removed. But maybe that "Done" is actually
> debugging output?
Yes, it is a debugging output.

> If what you want to convey to the users is that they can stop typing now...
> maybe you could say that directly instead of making them infer it from a line
> like:
> Available entropy: 256, Required entropy: 256 [100 %]
> which will fairly closely resemble the long list of lines that they've been seeing
> and hence may not communicate its true significance to them immediately.
I think this is a quite common pattern with progress bars and all these
progress displaying things that they finish and stay on "100 %" not "We
are done."

> I've actually been hitting random keys to increase entropy to 256
> recently to test a bug and watching that output gets boring fast.
> Also, maybe the line at the top should be more encouraging than informational.
> If the users have to type random keys to get out of their situation, they should
> probably get to read a line that tells them to do that, something like:
> "To supply additional entropy, type at random. Do not hold keys down."
The wording has to be improved and you're right it should probably
contain the word 'randomly' before the word 'typing'.

> And the concluding line should be something like:
> "Sufficient entropy generated. You may stop typing."
This could be added after the >= 100 % line, although I don't think it
would make a big difference for users.

Vratislav Podzimek

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

More information about the anaconda-patches mailing list