I have decided to omit in-depth discussion of a few interesting concepts, but these may be a valuable inspiration for further explorations.
In theory, it might be possible to deploy the PRNG timing attack over a network. Certain cryptography-enabled services implement symmetrical cryptography. After establishing a slower asymmetric stream using public key infrastructure and verifying both parties, a symmetrical session key is generated, and both endpoints switch to a faster symmetrical alternative.
It might be possible to time keystrokes by causing the application to exhaust an existing entropy pool in the system to the point that there is not enough entropy to seed a new session key, but only by a small fraction. The application will then delay generating a symmetrical key until enough entropy to seed the remainder of a key is available, and this will occur, among other possibilities, on the next key press or release.
It is my belief that the attack is more likely to succeed in a laboratory setup than in any real-world practical application, although my technical reviewer disagrees with my skepticism, and so, consider it to be merely an opinion. An interesting analysis from the University of Virginia criticized the original SSH timing research discussed in the paper mentioned before on the grounds that network jitter is sufficient to render timing data unusable, although it is worth noting that if a specific activity is repeated over time (for example, the same password is entered upon every login), random network performance fluctuations may very well average out.[51]
Some systems have better ways to recover the keystroke information and other timing data. After publishing my PRNG timing research, it was pointed out to me that Linux provides a /proc/interrupts interface that displays interrupt summary statistics, with the intention of providing some useful performance data. By examining interrupt counter changes for IRQ 1, it is possible to obtain the same timing information that is acquired via PRNG, already filtered of any eventual disk and network activity inclusions, thus causing a privacy exposure similar to the one discussed before.
Other issues worth considering are related to the PRNG implementation itself. Buying identical hardware in bulk and installing the same system on each device is a common practice and can be a problem for servers that do not experience heavy console activity. There is also a risk of mirroring an installation using specialized duplication tools and then propagating the image across a number of servers. In all situations, systems can end up with low real entropy for perhaps a bit too long.