[145326] in cryptography@c2.net mail archive
Re: Intel to also add RNG
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon Jul 12 14:24:21 2010
Date: Mon, 12 Jul 2010 13:04:20 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: cryptography@metzdowd.com
In-Reply-To: <20100712171310.GN3237@randombit.net>
On Mon, Jul 12, 2010 at 01:13:10PM -0400, Jack Lloyd wrote:
> I think it's important to make the distinction between trusting Intel
> not to have made it actively malicious, and trusting them to have
> gotten it perfectly correct in such a way that it cannot fail.
> Fortunately, the second problem, that it is a well-intentioned but
> perhaps slightly flawed RNG [*], could be easily alleviated by feeding
> the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take
> your pick I guess). And the first could be solved by also feeding your
> CSPRNG with anything that you would have fed it with in the absense of
> the hardware RNG - in that case, you're at least no worse off than you
> were before. (Unless your PRNG's security can be negatively affected
> by non-random or maliciously chosen inputs, in which case you've got
> larger problems).
You need an entropy pool anyways. Adding entropy (from the CPU's RNG,
from hopefully-random event timings, ...) and non-entropy (from a flawed
HW RNG, from sadly-not-random event timings, ...) to the pool results in
having enough entropy (once enough entropy has been added to begin
with). You'll want multiple entropy sources no matter what, to deal
with HW RNG failures for example.
BTW, SPARC CPUs have shipped with on-board HW RNGs; Intel is hardly
first.
Nico
--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
