Issue #15039 has been updated by Freaky (Thomas Hurst).


naruse (Yui NARUSE) wrote:
> Freaky (Thomas Hurst) wrote:
> > naruse (Yui NARUSE) wrote:
> > > 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 you've just described concerns over situations where such APIs are unavailable.  If you have no /dev/urandom why would you have a /dev/random?  If you have no non-blocking syscall for entropy why would you have a blocking one?

> But the size of those entropy is limited.

Entropy's not really limited, the entire point of CSPRNGs is that you can stretch 256 bits of entropy out practically forever because the effort required to recover those bits and predict anything *exceeds the physical limitations of the universe*.

> > 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.

http://man7.org/linux/man-pages/man2/getrandom.2.html

No it doesn't.  "*By default, getrandom() draws entropy from the urandom source*".

GRND_NONBLOCK's only affect is to return an error instead of blocking if the urandom source hasn't been seeded - i.e. very early in the boot sequence, which I'm not sure Ruby should be caring about.  /dev/urandom also blocks like this on most platforms.

----------------------------------------
Bug #15039: Random.urandom and SecureRandom arc4random use
https://bugs.ruby-lang.org/issues/15039#change-73807

* 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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>