Intel to also add RNG

Ben Laurie benl at google.com
Wed Jul 14 05:29:53 EDT 2010


On 12 July 2010 18:13, Jack Lloyd <lloyd at randombit.net> wrote:
> On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote:
>
>> BTW, let me note that if Intel wanted to gimmick their chips to make
>> them untrustworthy, there is very little you could do about it. The
>> literature makes it clear at this point that short of carefully
>> tearing apart and analyzing the entire chip, you're not going to catch
>> subtle behavioral changes designed to allow attackers backdoor
>> access. Given that, I see little reason not to trust them on an RNG,
>> and I wish they would make it a standard part of the architecture
>> already.
>
> 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).

Several years ago I reviewed a new design for FreeBSD's PRNG. It was
vulnerable to sources that had high data rates but low entropy (they
effectively "drowned out" lower data rate sources). This was fixed,
but I wonder how common an error it is?

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list