On 01/25/2011 06:30 AM, Sandy Harris wrote:
If an enemy gets root on your system, then your secure storage is no longer secure.
I believe the technical term for this is "pwned".
By all means, if you have something like /dev/random or another buffering scheme, store some state and throw it in after a reboot. It certainly cannot hurt and, if the file is secure, it helps a lot. But I think you also need some entropy-collecting activity to stir the pool so that, even if the state is compromised, the pool eventually becomes unknown to the enemy.
As mentioned, what if a VM snapshot were to leak out?My guess is in practice, most systems doing crypto are going to have some private keys being disclosed along with the CPRNG state. But perhaps DH forward secrecy is busted along with the disclosure of CPRNG state.
For example, OpenBSD uses RC4 as the PRNG for everything except the central entropy pool. Every /dev/*random device returns results from the same kernel instance of RC4, which is reseeded in predictable 10 minute intervals.
A. The output of RC4 has long been known to be subject to bias. See attached graph. The lines are confidence intervals which should be converging on the horizontal line, but clearly are not. It only takes a few megabytes of non-contiguous output samples to distinguish this from a real random source. I would expect one could observe this in just the TCP initial sequence numbers chosen by an OpenBSD box, given enough of them.
B. Another problem is that RC4 is not a one-way function, its state is invertible. So if the kernel state is compromised, the attacker can trivially obtain all random numbers generated on the system for a window of time up to 10 minutes in the past.
Does anyone else think this might represent a problem?I tried discussing (A) and some other concerns with the OpenBSD developers, but they became so distraught that I didn't have the heart to tell them about (B).
- Marsh
<<attachment: plot.png>>
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
