On Fri, Jul 18, 2014 at 1:28 PM, Paul Hoffman <[email protected]> wrote: > On Jul 18, 2014, at 11:19 AM, Leif Pedersen <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"