| HN Mirror

Couple things:

(i) arc4random is among the older of the widespread CSPRNGs (WinAPI CryptGenRandom is of the same vintage but has been updated).

(ii) arc4random is an implementation of RC4, which is not a well-regarded stream cipher particularly with regard to biases.

(iii) As I recall (note: I could be totally wrong here) arc4random depends on RC4 as its entropy management function; modern designs tend to use secure hash functions for this.

(iv) arc4random in isolation implements only one component of what Ferguson and Schneier would call a cryptographically secure random number generator (the "generator"); it doesn't handle entropy gathering, it doesn't handle heterogenous entropy sources, it doesn't manage entropy pools, and it doesn't build in functionality for handling cold starts (ie, it doesn't inherently persist its state).

One issue that encapsulates all of these (and also blunts any criticism you might perceive of OpenBSD in this comment) is that arc4random as implemented in OpenBSD is not the same thing as openbsd-lib/arc4random.c; OBSD handles entropy gathering, for instance, in the kernel. On the other hand, FreeBSD ignored some of these issues back in 2008 and had a cold start problem. Point being: if you just grab arc4random.c from OpenBSD CVS and stick it in your project, you probably hurt your security.

I like Thomas Pornin's suggestion to this on Stack Overflow: take AES (you probably have it in hardware on modern Intel chipsets) and run it in CTR mode, with random (from random sources) entropy keys (expanded with a fast secure hash), rekeying regularly; this has the advantage of keeping the RNG state in some sense away from attackers as well.

But of course what you really ought to do is just use /dev/random.