On 12 July 2010 18:13, Jack Lloyd <[email protected]> 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 [email protected]
