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
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.
>
> > I do not want to imply 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 us
y changed
> such that the output of RDRAND is now just XORed 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 functio
output 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 thi
