Differences between revisions 2 and 3
Revision 2 as of 2017-01-16 20:02:27
Size: 334
Comment:
Revision 3 as of 2017-01-16 20:28:06
Size: 2014
Comment: implementation, concerns
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:

== 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.

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.