From: naruse@... Date: 2018-08-30T07:49:07+00:00 Subject: [ruby-core:88745] [Ruby trunk Bug#15039] Random.urandom and SecureRandom arc4random use Issue #15039 has been updated by naruse (Yui NARUSE). Freaky (Thomas Hurst) wrote: > naruse (Yui NARUSE) wrote: > > I agree with your fundamental concept: if there's more code, there's more bugs. > > > > I don't fully agree with "userspace CSPRNG is harmful" because it's required. > > > > For example, ruby can't read /dev/urandom if it runs in jail. > > If the OS can't provide entropy to a process through urandom or an equivalent syscall, how is it going to safely seed a fallback CSPRNG? > > (Rust's rand can use JitterRng, for what it's worth: https://docs.rs/rand/0.5.5/rand/rngs/struct.JitterRng.html - seems a little esoteric). There's /dev/random and getentropy. But the size of those entropy is limited. > > And as Jeremy already pointend, OpenBSD doesn't have urandom alternative syscall because max output size of getentropy(2) is 256 bytes. > > (It means getentropy(2) is not a urandom alternative; just call getentropy(2) enough times is not acceptable) > > Therefore the use of arc4random(3) is not avoidable on OpenBSD. > > Both the existing /dev/urandom *and* getrandom() paths have to support calling their respective syscalls enough times to fill the requested bytes. > Why is it suddenly unacceptable when it's a guaranteed cap of 256 bytes instead of an arbitrary dynamic cap? > > getentropy() on OpenBSD is certainly a lot simpler to support than getrandom() on Linux. Linux's getrandom has flags argument. By default it behaves like getentropy and /dev/random, but if GRND_NONBLOCK is given it behaves like /dev/urandom. > > On Darwin, there seems similar issue as OpenBSD. > > SecRandomCopyBytes looks fairly sane: https://developer.apple.com/documentation/security/1399291-secrandomcopybytes?preferredLanguage=occ Thanks, I look it further. ---------------------------------------- Bug #15039: Random.urandom and SecureRandom arc4random use https://bugs.ruby-lang.org/issues/15039#change-73798 * Author: Freaky (Thomas Hurst) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Random.urandom defaults to arc4random() on a lot of platforms, including FreeBSD. On all currently released versions of FreeBSD, arc4random() is, as the name suggests, a dubious ARC4-based userspace PRNG dating from circa 1997. Given the entire point of #9569 was that using the userspace CSPRNG in OpenSSL over /dev/urandom or equivalent is a bad idea, this seems to mean it's regressed to an *even worse* state on these platforms. Even in cases where it's using something more modern (FreeBSD 12, OpenBSD), it's still a userspace CSPRNG. If that's fine, we might as well *pick a known-good one* and use that everywhere. Like, say, OpenSSL's. Since the conclusion of #9569 seems to have been otherwise, I'd suggest dropping arc4random() as a potential source for Random.urandom due to it not matching the desired semantics. Rust's OsRng seems a good template for alternative _syscall implementations: https://docs.rs/rand/0.5.5/rand/rngs/struct.OsRng.html#platform-sources -- https://bugs.ruby-lang.org/ Unsubscribe: