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


jeremyevans0 (Jeremy Evans) wrote:
> As the maintainer of the OpenBSD ruby port, I'm requesting that ruby continue to use arc4random_buf(3) on OpenBSD.  The OpenBSD getentropy(2) man page states:
> 
> ~~~
>      getentropy() is not intended for regular code; please use the
>      arc4random(3) family of functions instead.
> ~~~

I think there's a reasonable argument for providing access to both. What I'd like is:

1. Weak, fast random with an in-process Mersenne Twister or similar.

2. Strong, fast, crypto random.  Generated using an in-process CSPRNG.

3. Strong, slow, seed random.  Generated by either a system service or the kernel, with state managed *outside* the Ruby process.

Rust has these with `SmallRng` for 1, `StdRng` for 2, and `OsRng/EntropyRng` for 3.

Python has `random` for 1, `SystemRandom` for 3 (backed by `os.urandom`, which indeed uses OpenBSD's `getentropy()`).

Ruby has `Random` for 1, but 2 *or* 3 are provided by `SecureRandom`/`Random.urandom` depending on which platform you're on: 2 with `arc4random_buf()`, 3 with `getrandom()`/`CryptGenRandom`/`/dev/urandom`.

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

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