linux-kernel - Re: [PATCH] random: limit the contribution of the hw rng to at most half

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jul 2014 16:33:36 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	linux-crypto@...r.kernel.org
CC:	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] random: limit the contribution of the hw rng to at most
 half

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 default,
> but 97% seems to really way too much.
> 

OK, the that formula was Linus' suggestion.

> And the emergency refill code in random_read() was extremely
> problematic.  First of all, we're dropping 512 bytes on the stack,
> which is kind of bad, but hopefully all of the code paths which call
> random_read() won't have a terribly deep stack.

512 bytes is fine here (1K would possibly not have been.)

> Secondly, even after the emergency refill, we block anyway.

Not unless we don't get any data back.  For a nonzero return we loop
back to extract_entropy_user().

> Remember, regardless of whether or not you believe (as a former head
> of NSA's technology directorate recently claimed) that the DUAL-EC p
> and q were generated using NSA's standard high-quality HW RNG system
> which they use to generate all of their crypto variables, or (as the
> NIST advisory panel has recently concluded) that it was highly likely
> that DUAL-EC was backdoored, it's the optics that matter, because
> those of us without top-drawer SI security clearances can't prove
> things one way or another.

Dual-EC was also heavily criticized by the civilian cryptographic
community since at least 2006.

> And when 99.95% of the entropy when reading large quantities of keying
> material from /dev/random is coming from RDSEED, that just has
> terrible, terrible optics....

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.

I have no objection to the khwrngd route -- in fact, as you know, I have
been heavily encouraging the development of khwrngd with exactly this in
mind -- but it is just an issue of timing.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/