• via Digitalmars-d-bugs (74/74) Sep 14 2016 https://issues.dlang.org/show_bug.cgi?id=16493

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

https://issues.dlang.org/show_bug.cgi?id=16493

          Issue ID: 16493
           Summary: Request for an OS-independent interface to access
                    cryptographically secure pseudo random number
                    generators
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: phobos
          Assignee: nobody puremagic.com
          Reporter: ajidala gmail.com

Currently, phobos provides no way to gain platform-independent access to the
operating system's cryptographically secure random number generator.

Such generators are fed with entropy stemming from random hardware events such
as interrupt timing that only the kernel has access to, so most operating
systems implement an API to get random numbers from it.

The current lack of easy CSPRNG access means that developers may make poor
security choices out of either laziness or portability concerns.[1]

CSPRNGs are needed in any function where there is a need for sufficiently
random data in the face of an attacker willing to invest time and effort into
predicting RNG states. This includes uses such as generating password reset
tokens, or generating cryptographic keys. If one does not use a CSPRNG for
password reset tokens, a malicious third party could predict a password reset
token it triggered by sending itself a couple and thus figuring out what the
PRNG state is using off-the-shelf tools.

The implementation varies from platform to platform.

On Linux:
---------

For kernel versions below Linux 3.17, random data can be read from
/dev/urandom. However, /dev/urandom is not guaranteed to be initialised with
sufficient entropy early during the boot process. While many distributions
restore the previous RNG state into it and architectures such as x86 usually
provide enough entropy during boot for this to not be a big problem, embedded
platforms might not do so.

However, with kernel 3.17, a new syscall getrandom[2] was added. It allows to
block until at least 128 bits of entropy have been collected. It also does not
require to use a file descriptor, so random data can be acquired even if the
system is running out of fds (such as if an application doing encryption is on
a system that is under attack to try and starve it of fds).

The use of /dev/random on Linux is not needed (I'd link the talk about it if I
could find it at the moment). Essentially, /dev/random's wacky entropy-counting
and blocking is not what most (if not all) applications want, and does not add
any security unless you're talking about early boot (in which case it would do
the same as getentropy if getentropy was to block for initial seeding).

On Windows:
-----------

Windows offers an API to request CSPRNG data with CryptGenRandom[3]. First, a
CSP needs to be acquired, and the CSP needs to be destroyed after we're done
with it.

On OpenBSD:
-----------

OpenBSD has a syscall called getentropy[4], which inspired the Linux getrandom
syscall. getentropy does not allow requests for more than 256 bytes of data at
a time. However, it might also be sensible to use arc4random[5], it seems.
Python has a os.urandom module, maybe check what they do.

On other POSIX:
---------------

Reading from /dev/random is probably a good fallback for systems such as OS X.
I'm not sure what FreeBSD provides, but apparently it also has a /dev/urandom.
Someone please investigate.

Other OSes:
-----------

Fail loud and proud.

[1] https://github.com/brendanmckenzie/scrypt/issues/1
[2] https://lwn.net/Articles/605828/
[3]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx
[4] http://man.openbsd.org/getentropy.2
[5] http://man.openbsd.org/arc4random.3

--