On 18/07/14 20:01, Leif Pedersen wrote: > 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. Yes, it's one of many things that has gone wrong in the past. It's been pointed out to me that OpenBSD solved that particular issue with MAP_INHERIT_ZERO: the state of the arc4random PRNG is zeroed out on forking, and it knows to reseed then. FreeBSD since r227520 (2011-11-15), calls getpid() on every arc4random_buf call, to see if the pid has changed since it seeded, and thus reseed. It was shown recently (in the context of LibreSSL Portable) that this may not work in a contrived corner-case, so there they added an atfork handler, but again might not always be called. *If* getpid involves a syscall on every arc4random_buf call, that is going to already going to limit its performance? Would it really be any slower to just return random bytes from the kernel, with the KERN_ARND sysctl? The overhead of currently having to initially and periodically seed RC4, discard the early keystream, and apply that cipher thereafter, would be gone. The risk of the problem described above, or of weaknesses in RC4, or implementation issues with arc4random's PRNG seeding are also gone. And if FreeBSD's kernel CSPRNG wasn't trusted already, the arc4random PRNG is badly seeded and untrusted anyway. arc4random wasn't doing anything to supplement with entropy gathered from userland (which seems to be the belt-and-braces approach taken by OpenSSL). I don't suppose there's a risk of exhausting entropy by reading too much via the sysctl, or else an unprivileged user could do that already. Yarrow should already handle this. I very much welcome critique here, I think that's a necessary part of design and evolution of security code. I think we should periodically look at what we have to make sure it still holds up to scrutiny, even if it 'aint broke (as far as we know). Please point out any wrong assumptions you think I've made, even if it seems obvious. > will have exactly the > same initial state if there is no provision to reseed the PRNG. There is arc4random_stir, but an application could easily forget to do that. Users of libevent for example, which uses arc4random, doesn't expose an API function to do an explicit stir if the application forks. Regards, -- Steven Chamberlain [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"