Tom On Wed, Feb 25, 2015 at 6:21 PM, Tom Worster <f...@thefsb.org> wrote: > Hi Leigh, > >>We're still discussing whether a userland (non-kernel userland) >>implementation of arc4random is wise. We need to put some feelers out >>and consult some experts on this, > > I wouldn't. As Thomas Patcek put it, quoting the article I linked > before: > > You want to use the kernel's CSPRNG, because: > > * The kernel has access to raw device entropy. > > * It can promise not to share the same state between applications. > > * A good kernel CSPRNG, like FreeBSD's, can also promise not to feed > you random data before it's seeded. > > Study the last ten years of randomness failures and you'll read > a litany of userspace randomness failures. Debian's OpenSSH debacle? > Userspace random. Android Bitcoin wallets repeating ECDSA k's? > Userspace random. Gambling sites with predictable shuffles? Userspace > random. > > Userspace generators almost always depend on the kernel's generator > anyways. Even if they don't, the security of your whole system sure > does. A userspace CSPRNG doesn't add defense-in-depth; instead, it > creates two single points of failure.
The question came up while discussing potential bandwidth limitations of /dev/urandom and things like file descriptor exhaustion. So one of the thoughts we bounced was to use an internal arc4random implementation that was seeded the first use, and then re-seeded periodically (every x bytes or y seconds). Another thought to avoid the file descriptor issue was in newer kernels just tie in the linux getrandom(2) syscall and BSD getentropy(2) syscall directly. But based on getentropy(2)'s docs it specifies that it's only meant to seed an arc4 generator, not provide a stream of bytes. Overall the complexity prob isn't worth it (as you state). But the abstraction also doesn't depend on these details (so we can always change it later). Thanks Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
