Are we using /dev/urandom on Mac OS and is that a bad idea?

[NodeGuy]

The manual states:

On other Unices, the /dev/urandom device is used

I assume that applies to Mac OS. On Mac OS, /dev/urandom (which is the same as /dev/random) has several problems:

• Beware of /dev/random on Mac OS X
• Yarrow requires entropy estimation, which is a very big challenge for implementation. It is hard to be sure how much entropy to collect before using it to reseed the PRNG. This problem is solved by Fortuna (PRNG), an improvement of Yarrow. Fortuna has 32 pools to collect entropy and removed the entropy estimator completely.[1]
• Yarrow-160 uses SHA1, which has widely been considered deprecated due to its first public collision.[1]

From the Yarrow paper:

Like any other cryptographic primitive, a Yarrow generator has a
limited strength which we express in the size of the key. Yarrow-160
relies on the strength of three-key triple-DES and SHA-1. Systems that
have switched to the new cryptographic mechanisms (such as the new AES
cipher, when it is selected) in the interests of getting higher security
should also use a different version of Yarrow to rely on those new
mechanisms. If a longer key is necessary, then a future "larger" version
of Yarrow should be used; it makes no sense to use a 160-bit PRNG to
generate a 256-bit key for a block cipher, if 256 bits of security are
actually required.

From Mac OS's man page for /dev/urandom:

Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root. The
quality of its output is however dependent on regular addition of appropriate entropy. If
the SecurityServer system daemon fails for any reason, output quality will suffer over
time without any explicit indication from the random device itself.

Paranoid programmers can counteract this risk somewhat by collecting entropy of their
choice (e.g. from keystroke or mouse timings) and seeding it into random directly before
obtaining important random numbers.

Should Sodium supply its own CSPRNG (such as Fortuna, the improvement over Yarrow that FreeBSD switched to but Mac OS did not) instead of reading from /dev/urandom when on Mac OS?

[1] https://en.wikipedia.org/wiki/Yarrow_algorithm#Cons

[NodeGuy]

Hmm, I just found this blog article which suggests that using a user space CSPRNG is a bad idea:

https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

It looks like the correct security fix is for me to stop using Mac OS. :-(

[jedisct1]

/dev/urandom should be totally fine.

The mailing list post you mention was sent 15 years ago, and refers to a section of the man page that doesn't exist any more. The current code is here: https://github.com/opensource-apple/xnu/tree/53c5e2e62fc4182595609153d4b99648da577c39/osfmk/prng

SHA-1 collisions are also irrelevant to its use within a PRNG.

libsodium does ship with a userland PRNG even though it is not thread-safe and is never used by default. You can enable it with randombytes_set_implementation(&randombytes_salsa20_implementation). But macOS is fine, really.

[NodeGuy]

That man page is still in my copy of OX X El Capitan and the code you linked to is the same problematic Yarrow code but I appreciate your reassurance, thank you.

[FSMaxB]

@NodeGuy: The Yarrow code is still there, but I don't see it used in random.h and random.c (maybe I'm wrong?).

[NodeGuy]

At a cursory glance this comment in random.h suggests otherwise:

/*
 * Wrapper for requesting a CCDRBG operation.
 * This macro makes the DRBG call with pre-emption disabled to ensure that
 * any attempt to block will cause a panic. And the operation is timed and
 * cannot exceed 10msec (for development kernels).
 * But skip this while we retain Yarrow.
 */
#define YARROW 1

https://github.com/opensource-apple/xnu/blob/53c5e2e62fc4182595609153d4b99648da577c39/osfmk/prng/random.h#L76-L83