excessive usage of /dev/random?

[Bjarni Runar Einarsson]

Thanks for starting this discussion, Daniel.

I just wanted to chime in and point out that this decision has a cost
for the usability and complexity of apps like Mailpile, where the first
thing we do upon setup is create a key for the user if one does not
exist already. It's common for key creation (for a 4096 bit key) to take
over 10 minutes and I've seen it take well over 30.

This adds complexity, because:

a) waiting so long is an unacceptable user experience, so apps have to
be written create the key in the background and communicate progress to
the user somehow. This includes blocking or disabling elements of the UI
that depend on the key existing.

b) apps have to gracefully deal with the very common situation that the
user quits the app before the key creation has completed.

It may not sound like much, but this adds complexity all over the place
in the app (Mailpile does not get all this stuff right yet), both in
terms of code and communicating with the user. The alternative, asking
the user to "please wait half an hour" is just not acceptable.

If gnupg were more frugal with entropy, key creation would take less
time and this would be much less of an issue.

Note that I'm not asking that GnuPG compromise on security and trust
Werner and others more qualified to make safe choices in that regard.
However, this *is* slightly impacting the security of Mailpile, as I'm
probably not going to go with 4096 bit keys by default, simply because
creating them takes too long. I'm told 2048 is probably "good enough",
as a default, so that's what we'll be shipping.

So if there is indeed headroom to be more frugal with /dev/random and
speed things up corrospondingly, doing so has my vote!

Cheers,
 - Bjarni


Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> The argument that the man page makes (and that djb makes in
> http://blog.cr.yp.to/20140205-entropy.html) is that for a proper CSPRNG,
> you shouldn't really need more than 256 bits of true entropy to get a
> properly unbreakable seed.  "some safety margin above that minimum is
> reasonable", but going from 32 bytes to 300 bytes is a rather large
> safety margin.
...

-- 
Sent using Mailpile, Free Software from www.mailpile.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Secure_Headers.txt
Type: text/rfc822-headers
Size: 512 bytes
Desc: not available
URL: </pipermail/attachments/20150501/5ca0d062/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20150501/5ca0d062/attachment.sig>