Differences between revisions 3 and 4
Revision 3 as of 2017-01-16 20:28:06
Size: 2014
Comment: implementation, concerns
Revision 4 as of 2017-01-16 20:30:14
Size: 2052
Editor: GuillemJover
Comment: Linkify libbsd
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
arc4random(3) is random-number-generating library function, first available on BSD platforms, and also on GNU/Linux with libbsd. arc4random(3) is random-number-generating library function, first available on BSD platforms, and also on GNU/Linux with [[https://tracker.debian.org/libbsd|libbsd]].

arc4random

arc4random(3) is random-number-generating library function, first available on BSD platforms, and also on GNU/Linux with libbsd.

Manual pages

http://man.openbsd.org/?query=arc4random

https://www.freebsd.org/cgi/man.cgi?query=arc4random

https://manpages.debian.org/cgi-bin/man.cgi?query=arc4random

Implementation

arc4random initialises itself with some random bytes from the kernel, but rather than using those bytes directly, a stream cipher is used to produce longer streams of output. Re-seeding happens occasionally thereafter. If a process forks, it should explicitly re-seed to avoid each process sharing the same RNG state.

The function when originally implemented in OpenBSD, used the RC4 cipher to produce the output stream. OpenBSD now uses a ?ChaCha20 stream cipher.

libbsd changed from using RC4 to ?ChaCha20 in version 0.8.0 (Debian package version 0.8.0-1).

FreeBSD's libc still uses RC4 libkern/arc4random.c, but discards the first 1024 bytes of the stream cipher's output, to try to mitigate known weaknesses in the cipher.

https://svnweb.freebsd.org/base/head/sys/libkern/arc4random.c?view=markup

GNU/kFreeBSD provides only the libbsd implementation.

Similar code to arc4random can be found in libevent, and dozens of other free software programs.

Concerns

RC4 is not considered to be a cryptographically strong cipher any more.

Some implementations discard the first 1KByte of more of the keystream as a possible countermeasure, but some do not.

Some implementations don't re-seed reliably (or perhaps at all) when a process forks.

https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux

Some methods of seeding are unsafe, and failures cannot be indicated to the caller. In a chroot/jail environment, perhaps /dev/urandom is missing. Or if all file descriptors are exhausted, nothing can be read from there. OpenBSD and FreeBSD provide system calls that are hopefully guaranteed to succeed.