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 linux-cve-announce 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]

Message-ID: <20140717220806.GW1491@thunk.org>
Date:	Thu, 17 Jul 2014 18:08:06 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH] random: limit the contribution of the hw rng to at most
 half

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 implication was that this was a request from a specific customer who
> presumably have their own "audited" hardware RNG.

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.

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.  Secondly, even after
the emergency refill, we block anyway.  Which is kind of OK, but what
it means is that we are pulling 512 bytes from RDSEED, and giving
credit for 2048 bits of entropy; but since we block until the next
contribution from interrupt randomness, that means we get 1 bit from
the entropy randomness, and 2048 bits of entropy from RDSEED --- which
means that from the standpoint of entropy accounting, 99.95%
(2048/2049) of the entropy is coming from RDSEED when reading from
/dev/random when its entropy pool is empty.

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.

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....

						- Ted
--
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/