of RDRAND is now just XORed with the output of the
classic /dev/random behavior -- /dev/random is still blocking.
With the current development cycle for 3.15, the function arch_random_refill
is added as presented in [1]. It now uses RDSEED instead of RDRAND. Yet, the
way this function is called
with the output of the
classic /dev/random behavior -- /dev/random is still blocking.
Mixing in RDRAND into /dev/random and /dev/urandom is actually
With the current development cycle for 3.15, the function arch_random_refill
is added as presented in [1]. It now uses RDSEED instead of RDRAND
that Intel (or any other chip manufacturer that
will
hook into arch_random_refill) intentionally provides bad entropy (and this
email shall not start a discussion about entropy again), but I would like
to be able to only use noise sources that I can fully audit. As it is
with hardware, I am
On 05/11/2014 08:36 PM, Stephan Mueller wrote:
Ohh, ok, thanks for fixing that. :-)
Though what makes me wonder is the following: why are some RNGs forced to use
the hw_random framework whereas some others are not? What is the driver for
that?
The current state of random.c vs.
On 05/11/2014 08:36 PM, Stephan Mueller wrote:
But in our current predicament, not everybody trusts a few potentially easily
manipulated gates that have no other purpose than produce white noise which
are developed by the biggest chip vendor in the US. Gates which have other
purposes may
