On Thu, Jul 17, 2014 at 04:33:36PM -0700, H. Peter Anvin wrote:
>
> I just want to make sure we don't negatively impact the real security of
> users because of "optics". We already have a lot of problems with
> people extracting long-living keys from /dev/urandom because /dev/random
> is too slow
On 07/17/2014 03:08 PM, Theodore Ts'o wrote:
>
> There was another complaint more recently, that wasn't related to
> nordrand. And I was rather disturbed that in
> add_interrupt_randomness() 97% of the entropy was coming from RDSEED.
> I'm willing to have some of the entropy come from RDSEED by d
On Thu, Jul 17, 2014 at 10:39:57AM -0700, H. Peter Anvin wrote:
>
> I saw exactly one complaint to that nature, but that was from someone
> who really wanted the "nordrand" option (at which point I observed that
> it had inadvertently left RDSEED enabled which quickly got rectified.)
> The implica
On 07/17/2014 03:03 AM, Theodore Ts'o wrote:
> For people who don't trust a hardware RNG which can not be audited,
> the changes to add support for RDSEED can be troubling since 97% or
> more of the entropy will be contributed from the in-CPU hardware RNG.
>
> We now have a in-kernel khwrngd, so f
For people who don't trust a hardware RNG which can not be audited,
the changes to add support for RDSEED can be troubling since 97% or
more of the entropy will be contributed from the in-CPU hardware RNG.
We now have a in-kernel khwrngd, so for those people who do want to
implicitly trust the CPU
