Problem - Kevin Tafuro

Discussion
Stream ciphers are actually cryptographic pseudo-random number generators. One
major practical differentiator between the two terms is whether you are using the
output of the generator to perform encryption. If you are, it is a stream cipher; otherwise,
it is a cryptographic pseudo-random number generator.
Another difference is that, when you are using a stream cipher to encrypt data, you
need to be able to reproduce the same stream of output to decrypt the encrypted
data. With a cryptographic PRNG, there is generally no need to be able to reproduce
a data stream. Therefore, the generator can be reseeded at any time to help protect
against internal state guessing attacks, which is analogous to rekeying a stream
cipher.
The primary concern with a good cryptographic PRNG at the application level is
internal state compromise, which would allow an attacker to predict its output. As
long as the cryptographic algorithms used by a PRNG are not broken and the generator
is not used to produce more output than it is designed to support, state compromise
is generally not feasible by simply looking at the generator’s output. The
number of outputs supported by a generator varies based on the best attacks possible
for whatever cryptographic algorithms are in use.
The risk of state compromise is generally not a big deal when dealing with something
like /dev/random, where the generator is in the kernel. The only way to compromise
the state is to be inside the kernel. If that’s possible, there are much bigger
problems than /dev/urandom or CryptGenRandom( ) producing data that an attacker
can guess.
In the user space, state compromise may be more of an issue, though. You need to
work through the threats about which you are worried. Threats are likely to come
only from code on the local machine, but what code? Are you worried about malicious
applications running with the same permissions being able to somehow peer
inside the current process to get the internal state? If so, perhaps you should have a
separate process that only provides entropy and runs with a set of permissions where
only itself and the superuser would be a concern (this is the recommended approach
for using the EGADS package discussed in Recipe 11.8).
If state compromise is a potential issue, you might have to worry about more than an
attacker guessing future outputs. You might also have to worry about an attacker
backtracking, which means compromising previous outputs the generator made.
Reseeding the generator periodically, as discussed in Recipe 11.6, can solve this
problem. At best, an attacker should only be able to backtrack to the last reseeding
(you can reseed without new entropy to mix in).
In practice, few people should have to worry very much about state compromise of
their cryptographic PRNG. As was the case at the operating system level, if such
582 | Chapter 11: Random Numbers
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.