[Pki-clean-room-devel] Entropy gathering

[Daniel Kahn Gillmor]

Hi Rebecca--

On Thu 2018-03-01 22:42:05 +0000, Rebecca N. Palmer wrote:
> I did that, and it took ~10min of random typing to generate 4xrsa4096, 
> at an explicit "We need to generate a lot of random bytes" GPG prompt, 
> so it appears to me that GPG does wait for entropy and hence this isn't 
> a security problem.

This is not a security problem.  However, it *is* a usability problem
for GnuPG.  GnuPG does not need to block for as long as it did here, and
the fact that it's blocking for /dev/random indicates is a problem for
the usability of pki-clean-room. :/

I've just asked on gnupg-users at gnupg.org about any plans to move to the
more modern interfaces described in random(4), which should hopefully
address this usability concern.

> (This was done in my stretch-based cleanroom described at 
> https://lists.debian.org/debian-security/2018/02/msg00012.html , which 
> unlike this repository's, does *not* include haveged.  My hardware has 
> RDRAND, but I don't know whether anything was using it.)

I don't think you need to worry about the integrity of the key you
generated with that setup.

I *do* think we need to address the implications of this workflow for
pki-clean-room, though.  It's already pretty tough to get started with
anything like pki-clean-room.  if the user has to bang meaninglessly on
a keyboard for ~10 minutes to use the thing in the first place, i
believe that will turn people off.

bad usability is bad security, because people simply won't use the
security toolos have have bad usability in the first place.  They'll
resort to whatever they were using before.

pkg-clean-room should use tools that follow the guidance in random(4).

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pki-clean-room-devel/attachments/20180302/6755fefd/attachment.sig>