All of lore.kernel.org
 help / color / mirror / Atom feed
From: Folkert van Heusden <folkert@vanheusden.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: issue with /dev/random? gets depleted very quick
Date: Sun, 14 Jun 2009 21:58:54 +0200	[thread overview]
Message-ID: <20090614195854.GD7272@vanheusden.com> (raw)
In-Reply-To: <1245008055.4496.255.camel@calx>

[ /dev/random gets emptied very quickly ]
...
> > > Is this a problem? It really shouldn't be. Everyone should be
> > > using /dev/urandom anyway. And the anti-starvation threshold guarantees
> > 
> > Well, if I understood correctly how /dev/*random works, urandom is fed
> > by /dev/random. So if there's almost nothing left in the main pool and
> > urandom demands bits then we have an issue.
> > Also, if you frequently want to generate keys (thing gpg, ssl), I think
> > you want bits from /dev/random and not urandom.
> 
> There is really no difference.
> In an ideal world, we could accurately estimate input entropy and thus
> guarantee that we never output more than we took in. But it's pretty
> clear we don't have a solid theoretical basis for estimating the real
> entropy in most, if not all, of our input devices. In fact, I'm pretty
> sure they're all significantly more observable than we're giving them
> credit for. And without that basis, we can only make handwaving
> arguments about the relative strength of /dev/random vs /dev/urandom.
> So if you're running into /dev/random blocking, my advice is to delete
> the device and symlink it to /dev/urandom.

Two questions:
- if the device gets empty constantly, that means that filling
  applicaties (e.g. the ones that feed /dev/random from /dev/hwrng or
  from an audio-source or whatever)
- if we don't know if we're accounting correctly, why doing at all?
  especially if one should use urandom instead of random

> Also note that if something in the kernel is rapidly consuming entropy
> but not visibly leaking it to the world, it is effectively not consuming
> it.

Then the counter should not be decreased?

> In this case, if no one hears the tree fall, it hasn't actually fallen.
> There is exactly as much 'unknown' data in the entropy pool as before.
> If anything, the pool contents are now harder to guess because it's been
> mixed more.


Folkert van Heusden

-- 
MultiTail ist eine flexible Applikation um Logfiles und Kommando
Eingaben zu überprüfen. Inkl. Filter, Farben, Zusammenführen,
Ansichten etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

  reply	other threads:[~2009-06-14 19:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090614125138.GZ7272@vanheusden.com>
2009-06-14 15:51 ` issue with /dev/random? gets depleted very quick Matt Mackall
2009-06-14 19:04   ` Folkert van Heusden
2009-06-14 19:34     ` Matt Mackall
2009-06-14 19:58       ` Folkert van Heusden [this message]
2009-06-14 20:22         ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090614195854.GD7272@vanheusden.com \
    --to=folkert@vanheusden.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.