Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator[5] in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or Live CD systems such as routers and diskless clients, for which the bootup state is predictable and the available supply of entropy from the environment may be limited. For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot. In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state. This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.
It shouldn't be a religious but an engineering problem. If you manage keep some state between reboots and use it after the next reboot, you're making it hard enough for anybody not having the physical access to that state. Then you can also use RdRand to mix it with the output of your stream based on your state, and with other sources of entropy if you have them. If RdRand turns out to be suspicious, you're at least much better off than using only hard coded states.
Anybody knows if some kind of described state is used now?
My question was for /dev/random. The main problem RdRand solves is quantity: obtaining a lot of random bits per second. Even if they were produced in a way that somebody knows possible weaknesses, mixing them with something cryptographically strong where we control the seed we'd preserve quite a high throughput. I know that there is /dev/urandom which can often be good enough, but I know that too much applications in fact prefer to use /dev/random so making /dev/random robust has sense.
I see Ted Ts'o commented too, and as I understand, having RdRand is still much better compared to having the platforms without it. There's a lot more to care about than is RdRand "perfect" and once you have something like RdRand you can use it safely enough, compared to not having anything.
It applies to /dev/random too - the same write() implementation is used kernel-side for both devices so it doesn't matter which one you write to.
The seed that is saved at shutdown and reloaded at startup will alter the internal state of the /dev/random pool, but it won't add to the entropy estimate (which makes sense). This means that the output will be more robust, but it could still block waiting for "real" entropy.
http://en.wikipedia.org/wiki//dev/random
Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator[5] in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or Live CD systems such as routers and diskless clients, for which the bootup state is predictable and the available supply of entropy from the environment may be limited. For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot. In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state. This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.
It shouldn't be a religious but an engineering problem. If you manage keep some state between reboots and use it after the next reboot, you're making it hard enough for anybody not having the physical access to that state. Then you can also use RdRand to mix it with the output of your stream based on your state, and with other sources of entropy if you have them. If RdRand turns out to be suspicious, you're at least much better off than using only hard coded states.
Anybody knows if some kind of described state is used now?