Speed and security of /dev/urandom

[Leif Pedersen]

On Fri, Jul 18, 2014 at 9:26 AM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:

> On Jul 17, 2014, at 4:41 PM, Steven Chamberlain <steven at pyro.eu.org>
> wrote:
>
> > * after seeding, some arc4random implementations completely forget to
> > reseed after the process forks - the same 'random' stream of bytes could
> > occur twice, with security implications
>

This is a compelling argument to avoid doing crypto in isolation. One need
not do it in the kernel to avoid this (could implement a userland crypto
with a daemon that exports a pipe/socket), but the approach of seeding an
isolated algorithm that could wind up cloning it's memory space and
therefore the seed for the next value seems suboptimal.


> > (There's also the benefit that having many readers from a single
> > pseudorandom stream, adds an additional kind of randomness to its
> output).
>
> How does having an additional *reader* add additional bits?
>
>
The extra readers interrupt the position of the stream, so that it is
harder to predict the next value. This only works if one instance of the
PRNG is shared by multiple readers, rather than each reader operating in
isolation.

> This is obviously a complex issue, and some of it will be subjective.
> > But I welcome your comments.  Thanks!
>
> Subjective wins.
>

It's disappointing when emotions bewilder clear rational thinking. I think
his point is well stated.

Seeding a PRNG from another PRNG (such as seeding arc4random from FreeBSD's
Yarrow-backed /dev/random) increases risk since if the seed is compromised
then the dependent is also. Not to confuse that with xoring the output of
two PRNGs, which can't hurt and may help. I read that sending all hardware
randomness through Yarrow is in response to the questionable
trustworthiness of hardware randomness; fair enough. It then seems to me
that all programs should leave stretching the randomness to the kernel (or
other shared resource) rather than instantiating arc4random or the like and
only spooning out a little of the result to seed. That way, if the
algorithms or randomness backing /dev/random is compromised, one need only
patch one piece of software rather than many. Better yet, an operator can
potentially choose this or that algorithm system-wide with sysctl, if
multiple become available and one is compromised. In the final analysis, if
OpenSSL really can't trust /dev/random, then it should xor the stream from
/dev/random with its internal arc4random stream, not merely seed arc4random
from Yarrow, but even better to solve the trust problem in the kernel
rather than solve it selfishly in OpenSSL only for OpenSSL.

- Leif


-- 

As implied by email protocols, the information in this message is
not confidential.  Any middle-man or recipient may inspect, modify,
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  As the sender, I acknowledge that
I have a lower expectation of the control and privacy of this message
than I would a post-card.  Further, nothing in this message is
legally binding without cryptographic evidence of its integrity.

http://bilbo.hobbiton.org/wiki/Eat_My_Sig