On Fri, Jul 18, 2014 at 9:26 AM, Paul Hoffman <[email protected]> wrote: > On Jul 17, 2014, at 4:41 PM, Steven Chamberlain <[email protected]> > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"