From the libsodium developers:

On MacOS:

• arc4random() is not available on older versions of MacOS
• arc4random() seems to read /dev/random to reseed itself, and opens/closes the file every time. Which is not safe in a chroot()ed environment and violates libsodium guarantees
• before MacOS 10.2, arc4random() was actually using RC4, which should not be used for cryptographic keys due to biases.

It seems arc4random on osx is actually a userspace PRNG, which is not what we want here.

@RX14 - Based on my current research.

• arc4random introduced in macOS 10.6 (2009)

• arc4random_buf introduced in macOS 10.7 (2011)

• arc4random is reseeded with getentropy, not /dev/[u]random

• The documentation explicitly states to use arc4random as it is safe in chroot.

man arc4random:

They can be called in almost all environments, including chroot(2), and their use is encouraged over all other standard library functions for random numbers.

• arc4random is based on an AES cipher as of macOS 10.12 (2016)

• With regards to whether you should use arc4random or /dev/urandom/. The documentation is explicit. You should always use arc4random.

man random:

Applications requiring cryptographic quality randomness should use arc4random(3).

man urandom:

The same random data is also available from getentropy(2). Using the getentropy(2) system call interface will provide resiliency to file descriptor exhaustion, chroot, or sandboxing which can make /dev/random unavailable. Additionally, the arc4random(3) API provides a fast userspace random number generator built on the random data source and is preferred over directly accessing the system's random device.

man getentropy:

However, it should be noted that getentropy() is primarily intended for use in the construction and seeding of userspace PRNGs like arc4random(3) [...].

Its great that libsodium thinks they can do better. OpenBSD I am sure goes even further then libsodium. But I am not proposing we shim in (if even possible) OpenBSD's implementation or link in yet another library. Crystal should use the fastest/best built-in CSPRNG. On Darwin based systems that is arc4random.

I'd trust the libsodium guys far far more than you or I. If they say it's wrong, it's wrong. And risking this just for performance?

@RX14 - You can trust whoever you like. I don't trust the libsodium guys and I would certainly trust the Apple guys before them with regards to how something is implemented in macOS.

I happen to be of the perspective everyone should just duplicate OpenBSD's arc4random and keep it up to date. That isn't the case though. What is the case is macOS has /dev/urandom and their implementation of arc4random.

All the official documentation says use arc4random, as does the preponderance of unofficial documentation/discussions. arc4random is a better choice then /dev/urandom on macOS.

In case I need to say it again. Apple explicitly says:

Applications requiring cryptographic quality randomness should use arc4random(3).

and,

Additionally, the arc4random(3) API [...] is preferred over directly accessing the system's random device.

And until recently the linux manpages said using urandom wasn't cryptographically safe, which was against the advice of every cryptographer out there.

At the end of the day, this is a performance problem, and if there's any conflict at all, i'd rather stick with what we know works and is secure.

So, there are two main problems with arc4random

• it is userspace (so some side-channel attacks can be possible, but this possibility is debatable). There are controversial opinions about it.
• it can use RC4 (that is nonuniform and generally broken) on old systems.
  Checking the source confirms, that macOS 10.12 (Sep 20, 2016) uses AES and 10.11 uses (modified but still unreliable) RC4 seeding it from /dev/random.
  https://opensource.apple.com/source/Libc/Libc-1158.1.2/gen/FreeBSD/arc4random.c.auto.html
  https://opensource.apple.com/source/Libc/Libc-1081.1.3/gen/FreeBSD/arc4random.c.auto.html

so even if we ignore first point, arc4random shouldn't be used on OSX10.11 and older.

On the other hand, getentropy was introduced in macOS 10.12 (Sep 20, 2016) and is a (strictly) better solution then /dev/urandom - it yields same data (not a userspace prng) and is safer because doesn't depends on file descriptors. So if a getentropy is available - it is a modern OSX and we can use either arc4random or getentropy (depending on the opinion about first point).

On the other other hand, it a libsodium issue cited before tells that getentropy uses \dev\urandom. I think the additional research is needed on this, man page isn't a proof.
From what Apple opensourced

if (getentropy(buf, size) == 0) {
		return;
	}
	// The above should never fail, but we'll try /dev/random anyway

so it in theory can fallback to reading from /dev/random, but does it possible in practice depends from can getentropy fail. I wasn't able to find getentropy source to check.

And even if arc4random is secure on 10.12, are all the runtime checks and complexity (read: vulnerabilities) worth it? Just for some performance?

Closing. We can't trust ourselves on security topics. We need strong guarantees from cryptographers that something is safe and correct.

Sadly, we don't have enough guarantees that arc4random is cryptographically correct on macOS. The only guarantee we have is that it was very bad prior to macOS 10.12 😞