Date: Mon, 23 Jun 2014 17:42:24 +0000
From: David Holland <dholland-sourcechan...@netbsd.org>
On Mon, Jun 23, 2014 at 02:14:10PM +0000, Taylor R Campbell wrote:
> Add `remove arc4random' to mythical libc major bump todo list.
I'm not saying I disagree, but what's new code supposed to use
instead? (And can a reference to this be stuffed into the man page?)
Read from /dev/urandom. It scales better in multithreaded programs,
avoids fork issues (hanging, duplicate key streams, disclosure of
parents' secrets in unprivileged children), and works on ~any Unix,
not just on OpenBSD and whoever else parroted arc4random.
If you really need to randomly generate bits at higher throughput,
read a key from /dev/urandom and feed it to a stream cipher that is
fast enough, e.g. Salsa20 or ChaCha, or if you need even higher
throughput, Salsa20/8 or ChaCha8. But only if you actually observe
/dev/urandom to be your bottleneck.
IF you observe /dev/urandom to be your bottleneck, or if you need
reproducible results, you might see, e.g., the miniature CPRNG API in
this reimplementation of arc4random(3) with ChaCha:
https://www.NetBSD.org/~riastradh/tmp/20140622/arc4random.c
It may be worthwhile to provide a simple API like that in libc, which
you can use in a thread-local data structure and either seed from
/dev/urandom for production or use a fixed seed for reproducible
results.
Or it may be worthwhile to provide an API that seeds itself from
/dev/urandom (or sysctl(kern.urnd)) and keeps per-thread state and
manages zeroing the state on fork, as in
https://www.NetBSD.org/~riastradh/tmp/20140622/arc4random_tsd.c
Or it may be worthwhile to mostly keep the way arc4random(3) works but
replace the PRNG, as in the first reimplementation of arc4random(3)
above, but rename it. With either of the later two cases, perhaps we
ought to just coopt random(3) for the purpose.
