[115156] in cryptography@c2.net mail archive
Re: Toshiba shows 2Mbps hardware RNG
daemon@ATHENA.MIT.EDU (Dan Kaminsky)
Fri Feb 15 13:47:01 2008
Date: Fri, 15 Feb 2008 01:47:45 -0800
From: Dan Kaminsky <dan@doxpara.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
CC: david_koontz@xtra.co.nz, hal@finney.org, cryptography@metzdowd.com
In-Reply-To: <E1JPVOG-0001xu-Kp@wintermute01.cs.auckland.ac.nz>
Peter Gutmann wrote:
> "David G. Koontz" <david_koontz@xtra.co.nz> writes:
>
>
>> Military silicon already has RNG on chip (e.g. AIM, Advanced INFOSEC Machine,
>> Motorola),
>>
>
> That's only a part of it. Military silicon has a hardware RNG on chip
> alongside a range of other things because they know full well that you can't
> trust only a hardware/noise-based RNG, there are too many variables and too
> many things that can go wrong with that single source. That's why I was
> sceptical of the "we've solved the RNG problem with our custom hardware"
> claim, they've created one possible source of input but not a universal
> solution.
>
> Peter.
>
Peter, you've just hit on something that's genuinely confused me for
quite some time. Combining hash functions has always seemed naive --
the problem with chaining two different functions is that it creates a
midpoint; you can collide half the bitspace independently of the other
half. Better to just thoroughly mix them both. But shouldn't it be an
improvement to XOR a theoretically correct RNG with a well seeded PRNG,
based on the theory that:
1) Either generator could be safely XOR'd against a repeated series of
0x41's, and the output would still be just as random
2) The flaws of a subtlety broken RNG would be difficult to exploit
through the noise of a sufficiently validated cryptographic function,
and vice versa
For example, the following construction:
Start with an RNG. Retrieve 64K of "random data". Assume there might
be a bias somewhere in there, but that at least 256 bits are good.
SHA-256 the data. AES-256 encrypt the data with the result from the
SHA-256. XOR the random data against its encrypted self. Return 64K of
PNRG-hardened RNG data.
Aside from the obvious rejoinder to maybe XOR *another* batch of entropy
against the previous batch's encrypted self (a change that halves
performance), I can't see much wrong. I rather deeply doubt I'm the
first to come up with a suggestion like that either. So, uh, why do
weak RNG's keep showing up? Is there something fundamentally breakable
in the above design?
--Dan
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
