From: tom@...
Date: 2018-08-29T16:16:04+00:00
Subject: [ruby-core:88735] [Ruby trunk Bug#15039] Random.urandom and SecureRandom arc4random use
Issue #15039 has been updated by Freaky (Thomas Hurst).
jeremyevans0 (Jeremy Evans) wrote:
> Freaky (Thomas Hurst) wrote:
> > Would rand() stop being a userspace PRNG if it automatically called srand() every 200,000 calls?
>
> If it received the argument to srand() from the kernel, then maybe. :)
Even if that were the case, it's storing its state in userspace, it's permuting that state in userspace. Where it comes from is beside the point, as is how often it's reseeded. Would you still think it might stop being userspace if reseeds happened every 2 million calls? 2 billion?
The only distinction for "userspace PRNG" that makes sense as far as I can see is whether or not it runs predominantly in userspace. If you're not asking the kernel *each time*, you have a userspace PRNG.
> I think in general SecureRandom doesn't need to specify how it is implemented, just that the related bytes are cryptographically random.
It currently does specify vaguely how it's implemented, albeit incorrectly:
https://ruby-doc.org/stdlib-2.6.0.preview2/libdoc/securerandom/rdoc/SecureRandom.html
It's also quite vague about what it's suitable for. "session keys in HTTP cookies, etc" :/
> If that isn't true on FreeBSD <12, then I agree Ruby should use a different approach in that case, but let's limit any changes to that specific case (or other specific cases known to be problematic).
I strongly suggest doing it the other way around. Don't blacklist known-problematic implementations, carefully whitelist known-good ones.
I think NetBSD >= 7, FreeBSD >= 12 and OpenBSD >= 5.5 should all be reasonable, DragonFlyBSD is less so.
> > Calling an OpenSSL reseed function occasionally wasn't a more complex change than reworking the Random/SecureRandom framework to favour the equivalent of /dev/urandom on popular platforms. Nor is calling getentropy() any more complex than only calling arc4random() when the implementation is sane.
>
> I think manual reseeding using the OpenSSL PRNG is significantly more complex than just calling arc4random_buf.
It's not "just calling arc4random_buf", it's calling arc4random_buf where available, calling getrandom where available, calling CryptGenRandom where available, using /dev/urandom where available. Those are what resolved #9569, a fair bit of effort, when *by your argument* it might as well have just been a tweak to ossl_rand_bytes() like:
static int until_reseed = 1600000;
until_reseed -= n;
if (until_reseed <= 0)
RAND_poll();
Because then it wouldn't be a userspace CSPRNG, right? :P
> That recommendation does not necessarily apply to operating systems other than FreeBSD.
The arguments against userspace CSPRNG are fairly general: they add additional points of failure for the sake of performance.
> It sounds like you want a new feature: (SecureRandom|Random).sysrandom (analog of File#sysread, which does a system call for every method call).
I'd rather have `SystemRandom` that was guaranteed to do a syscall, then it can have all the same utility methods and pretty much be a drop-in replacement for SecureRandom where desired.
A `CryptoRandom` counterpart always guaranteed to be a decent fast userspace CSPRNG might be nice, too.
Which `SecureRandom` should behave like is bit of a bikeshed. I'd look at `Secure` and wiggle my eyebrows. Keeping CSPRNG state in the kernel is more secure, right? And this is how it already behaves on Linux and Windows.
----------------------------------------
Bug #15039: Random.urandom and SecureRandom arc4random use
https://bugs.ruby-lang.org/issues/15039#change-73789
* 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>