[Cryptography] What's a Plausible Attack On Random Number Generation?

[Jerry Leichter]

On Oct 31, 2013, at 2:48 PM, David Mercer <radix42 at gmail.com> wrote:
> Your datacenter description is a pretty good match for what I've seen in the last 10+ years for decently high-end facilities. The main flaw I can see is in using the network for entropy on boot up, especially on first boot. As there are quite a few services starting up that need good random numbers in most systems, you are as you say going to wait a while to grab enough entropy. Your entropy collection is going to have to start so early in the boot process that you aren't going to be sending out much, if any, network traffic, and are not going to be getting much of it.  
> 
> You need to wait to start up any services that use encryption of any kind, and which use it you can't know about ahead of time, so you need to start before pretty much anything else. Which means before all the things that might send out network traffic.
> 
> Listening promiscuously is NOT going to help, as you're going to be on a dedicated switch port. The only thing to listen to is the switch. Maybe some arp packets or similar?? 
Damn; I keep coming back to old technology from back when I worked at this level.  Yes, forget promiscuous mode.

> Sticking a transparent bridge machine between a system being measured and a switch port and sniffing everything travelling between them would let you see what network traffic you get in a real world install and first boot scenario.
Or maybe what's needed is a "beacon":  A system out there that grabs traffic - even from the Internet to make sure there's always stuff flowing, cryptographically hashes it, and sends it to a multi-cast address.  Use by L2 and L3 multi-cast as they'll have very different propagation properties and dependencies.

> "First boot" really refers to "first post-install boot", and is one of the lowest entropy points in a systems life-cycle.
Yes.

> If you start collecting entropy during the installation, when lots of network packets are likely to be flying around, and save the RNG state so that it has a decent amount of entropy saved on "first boot". If your install process sucks down your entropy pool, you might not have much to save, and you'd have to save the amount of entropy estimated remaining when you saved it's state. 
I'm deliberately assuming exactly two sources of entropy:  Contents and detailed timing of network packets; and allegedly-random bits delivered from other machines.  The problem at first boot is that (a) in a switched environment, I won't be seeing any real traffic; (b) I don't know who to ask for my random bits.

So actually the "beacon" should be done differently.  Every existing system that already has access to randomness, will periodically multicast some "random bits".  A newly booted system is able to see this stuff (it will have to know where to look, of course).  The bits themselves aren't particularly useful, but the timing information should be.  But you can bootstrap:  Once you think you've seen enough timing information to be hard to predict, start using your own generator to decide whether to include or skip packets as they arrive.

                                                        -- Jerry