[Cryptography] combining lots of lousy RNGs ... or not
tytso at mit.edu
Wed Nov 23 22:28:38 EST 2016
On Wed, Nov 23, 2016 at 02:39:17PM +0000, Jason Cooper wrote:
> Ted's example should really be, with no control of the hardware executed
> H(squish_NSA | squish_KGB | squish_MSS | squish_IRQ | squish_ADC)
> Once a system gets at least 128 bits from IRQ or ADC, the feasibility of
> any attack vector, even with knowledge of other attack vectors, goes
> drastically down.
Well, yes. I was trying to keep things simple. The other thing trick
is that there may be things like inter-packet arrival times on the
local ethernet, which may be observable to someone on the local
segment, might not be observable to an analyst sitting in Fort Meade
who hasn't managed to install a device on your local network. And
even if it is, the local Russian Mafia hacker might not have access to
it. So mixing in things like Squish_network_timing doesn't hurt, and
it might help.
> If we're designing the whole product, John's approach is the only
> correct one. If we have no control of the hardware we are executing on,
> then Ted's is strictly better than using any available individual source
If you are designing the whole product, and you have complete control
over the supply chain and manufacturing process, *and* you are sure
that you have control over the completed product from the assembly
plant to where it is deployed (so a friendly neighborhood NSA TAO team
hasn't intercepted the product while it is being shipped), then John's
approach can work.
But otherwise, ***any*** hardware random number generator is almost by
definition "squish". This includes things like Altus Metrum's
"ChaosKey" product, for example --- how do you know that you can
trust the ARM SOC on the sucker? And I say this while having the
utmost respect for Keith Packard and Bdale Garbee.
More information about the cryptography