linux-kernel - Re: issue with /dev/random? gets depleted very quick

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1245010943.4496.261.camel@calx>
Date:	Sun, 14 Jun 2009 15:22:23 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Folkert van Heusden <folkert@...heusden.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: issue with /dev/random? gets depleted very quick

On Sun, 2009-06-14 at 21:58 +0200, Folkert van Heusden wrote:
> [ /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)

This question appears incomplete. Also, your device is not 'getting
empty'.

> - if we don't know if we're accounting correctly, why doing at all?
>   especially if one should use urandom instead of random

Inertia.

> > 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?

There's no way for us to know. In other words, the counter isn't
terribly meaningful in either direction.

-- 
http://selenic.com : development and support for Mercurial and Linux


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/