On Pá, 2015-10-23 at 15:22 +0200, Alessandro Ghedini wrote:
...
> BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to
> RAND_bytes(). Additionally, if the RDRAND instruction is available, the output
> of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses
> thread-local storage to keep the global RNG state.
...
> The BoringSSL method is very simple but it needs a read from /dev/urandom for
> every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes()
> seems to implement some sort of buffering for /dev/urandom so the cost may be
> lower).
>
> On the other hand, LibreSSL replaced the whole RAND_* API with calls to
> OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to
> mix the internal RNG state, which is regularly reseeded from the system RNG.
> The core logic of this (excluding ChaCha20 and platform-specific bits) is
> implemented in less than 200 lines of code and, at least in theory, it's the
> one that provides the best performance/simplicity trade-off (ChaCha20 can be
> pretty fast even for non-asm platform-generic implementations).
>
> Both of these methods are robust and mostly platform-indipendent (e.g. none of
> them uses the system time, PID or uninitilized buffers to seed the RNG state)
> and have simple implementations, so I think OpenSSL can benefit a lot from
> adopting one of them. The astute readers may point out that OpenSSL doesn't
> support ChaCha20 yet, but that's hopefully coming soon.
How these libraries handle generation of random numbers after the
fork()? The mixing in of the system time & PID before pulling bytes from
RNG prevents sharing two identical streams of random numbers among
forked processes. If there is a buffering of data pulled from the kernel
RNG it is not sufficient to just say that all the data are pulled from
the kernel and thus unique.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
