[Cryptography-dev] OpenSSL Random Engine PR

[Alex Stapleton]

So in conclusion we don't have a particularly solid reason to avoid doing 
this (might reduce entropy_avail more than normal maybe) and have at least 
one very good reason (repeated RNG state) to do it?

Sent with AquaMail for Android
http://www.aqua-mail.com


On 20 January 2014 22:09:39 Laurens Van Houtven <_ at lvh.io> wrote:
> On Mon, Jan 20, 2014 at 11:04 PM, Glyph Lefkowitz
> <glyph at twistedmatrix.com>wrote:
>
> > FreeBSD and OS X use Yarrow, and Windows uses Fortuna, so nobody but Linux
> > even has an exhaustible / blocking random "real actual for real entropy"
> > API.  You can still exhaust the seed pool but as far as I know it would be
> > literally impossible to tell (like, mathematically provably impossible by
> > the properties of the various CSPRNGs used) that you had done so.
> >
> On Linux, /dev/random might still block sometimes, so you can tell that way
> > as a regular user, and your applications might get stuck.
> >
> > At least, as far as I know.  The usual caveats about me not being a
> > cryptographer, or actually knowing really anything about anything at all,
> > apply.
> >
> > -glyph
> >
> >
> I'm familiar with the CSPRNGs in modern OSes; I just thought we were
> talking about exhausting the entropy of the CSPRNGs (so, say, urandom on
> Linux and (u)random on FreeBSD and CryptGenRandom on Windows). IIUC, none
> of the systems in play here actually use /dev/random in steady state (just
> for key generation maybe). If the grandparent indeed meant /dev/random vs
> /dev/urandom on Linux that would explain why, yes :-)
>
> (FYI, I've yet to hear a cryptographer whose opinion on the blocking
> /dev/random because better entropy in Linux isn't that it's pretty much
> hogwash. djb is convinced they should just give up trying and implement
> Fortuna or Yarrow already.)
>
> cheers
> lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140120/7332f202/attachment-0001.html>