On 07/25/2012 08:16 PM, H. Peter Anvin wrote:
On 07/25/2012 08:10 AM, Theodore Ts'o wrote:
Aside from whether it's better to do this step in
xfer_secondary_pool() or extract_entropy() ...
By the way, I looked at doing this in xfer_secondary_pool()... the
problem there is that xfer_secondary_po
On 07/25/2012 08:10 AM, Theodore Ts'o wrote:
Aside from whether it's better to do this step in
xfer_secondary_pool() or extract_entropy() ...
By the way, I looked at doing this in xfer_secondary_pool()... the
problem there is that xfer_secondary_pool() is called exactly once per
invocation of
On 07/25/2012 08:10 AM, Theodore Ts'o wrote:
RDRAND is already getting mixed in already in xfer_secondary_pool() so
we are already taking advantage of Bull Mountain (or any other
CPU/architecture-specific hw RNG) if it is present.
You generate an arbitrary 16 or 32 bytes of RDRAND in one plac
On Tue, Jul 24, 2012 at 08:37:23PM -0700, H. Peter Anvin wrote:
>
> As a compromise I offer the following patch; in terms of performance
> it is "the worst of both worlds" but it should provide the combined
> security of either; even if RDRAND is completely compromised by the
> NSA, Microsoft and
* H. Peter Anvin wrote:
> For those who have read the Google+ thread[1] it is pretty
> clear that there are varying opinions on the idea of removing
> the RDRAND bypass.
>
> I have gathered some performance numbers to make the debate
> more concrete: RDRAND is between 12 and 15 times faster
For those who have read the Google+ thread[1] it is pretty clear that
there are varying opinions on the idea of removing the RDRAND bypass.
I have gathered some performance numbers to make the debate more
concrete: RDRAND is between 12 and 15 times faster than the current
random pool system (f
6 matches
Mail list logo
