Date: Fri, 18 Jul 2014 14:01:53 -0500 From: Leif Pedersen <bilbo@hobbiton.org> To: Paul Hoffman <paul.hoffman@vpnc.org> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, Steven Chamberlain <steven@pyro.eu.org> Subject: Re: Speed and security of /dev/urandom Message-ID: <CAK-wPOhUDhzB6mXJ4XSCN4O6VcyPG9dXqtQJkR3Eoj6Q_gZ=Xg@mail.gmail.com> In-Reply-To: <C9E21765-D47F-4D98-8C7A-FCD9922FD072@vpnc.org> References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> <CAK-wPOhuh_XUpQ9OZXB1UZjz6wQF=8gO2thWiBu9i3tt%2BKt7mQ@mail.gmail.com> <C9E21765-D47F-4D98-8C7A-FCD9922FD072@vpnc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 18, 2014 at 1:28 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Jul 18, 2014, at 11:19 AM, Leif Pedersen <bilbo@hobbiton.org> wrote:
>
> > 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.
>
> If there was a non-zero chance that an attacker could predict the next
> value, your PRNG was already broken. Two of the fundamental properties of a
> working PRNG is that if an attacker sees any number of outputs from the
> PRNG, the attacker cannot compute any previous values and the attacker
> cannot predict any future values.
>
>
if(! fork()) {
int x = next_value();
// Do something that depends on the sensitivity of x here.
} else {
// exec untrusted program here...
// distrusted program:
int x = next_value();
printf("Known value: %i\n", x);
}
This has nothing to do with the quality of the PRNG or being otherwise
compromised. It's that after being seeded the PRNG operates in isolation
and the memory space is cloned exactly. PRNGs run on computers which are
currently deterministic, so there is no algorithm that can yield different
values for x in the two branches.
Crypto libraries frequently fork untrusted processes, for example sshd
accept()s, fork()s, does crypto, switches users, and forks a shell. Every
child would have the same initial state at the "does crypto" part, and so
must be reseeded. Web servers work similarly. Apache is more complicated
because one child accepts many connections, but ultimately they always
terminate and are replace by another sibling which will have exactly the
same initial state if there is no provision to reseed the PRNG.
I believe one of Steven's points was (I'm fairly sure I understood him
correctly) that neglecting to reseed after fork() has led to problems.
- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK-wPOhUDhzB6mXJ4XSCN4O6VcyPG9dXqtQJkR3Eoj6Q_gZ=Xg>