# What is the difference between CSPRNG and PRNG?

Is there performance differential between them? For example: we use PRNG for key generation which is very expensive and CSPRNG for IV/nonce in block ciphers which is fast? What is the difference between the two types of RNGs?

-
Since a CSPRNG will also be a PRNG, if your choice of CSPRNG is faster than your choice of PRNG you might as well swap and use the CSPRNG for both (which you almost certainly should be anyway) –  figlesquidge Dec 18 '13 at 17:06
Paraphrasing John Von Neumann (as cited by Donald E. Knuth in Chapter 3 of TAOCP), One that considers using a PRNG (or only a CSPRNG) for key generation is, of course, in a state of sin. –  fgrieu Dec 18 '13 at 17:06
What research have you done? After all, Wikipedia's "Cryptographically secure pseudorandom number generator" and "Pseudorandom number generator" already provide a pretty good insight into the difference between them two. –  e-sushi Dec 18 '13 at 17:07
@fgrieu Makes me think… wouldn't that exclude the human brain too? After all, it's known to also be a rather bad and baised PRNG. ;) –  e-sushi Dec 18 '13 at 17:08
PRNG encompasses all pseudo random number generators, from the horrible rand call in c, over suitable for simulations but not security ones like the mersenne twister, to the most secure cryptographic PRNG. CSPRNGs are simply the subset of PRNGs which are secure. Every stream cipher, including AES-CTR can act as CSPRNG. Depending on the context, one might also include the proper seeding in the scope, which is far more complex than the actual data generation. –  CodesInChaos Dec 18 '13 at 18:42

"PRNG" means "Pseudorandom Number Generator" which means that a sequence of numbers (bits, bytes...) is produced from an algorithm which looks random, but is in fact deterministic (the sequence is generated from some unknown internal state), hence pseudorandom.

Such pseudorandomness can be cryptographically secure, or not. It is cryptographically secure if nobody can reliably distinguish the output from true randomness, even if the PRNG algorithm is perfectly known (but not its internal state). A non-cryptographically secure PRNG would fool basic statistical tests but can be distinguished from true randomness by an intelligent attacker.

For instance, consider the following generator:

• There is an internal state s which is a sequence of 20 bytes.
• The generator produces a long sequence of bytes by 20-byte chunks.
• To produce the next chunk, the algorithm is: output s, then set s to SHA-1(s).

This PRNG will be very good statistically, but it is trivial to distinguish from true randomness: just take two consecutive 20-byte chunks in the output, and see if the second is the result of SHA-1 over the first. This is not a cryptographically secure PRNG.

Of course, every CSPRNG is a PRNG, but not every PRNG is a CSPRNG. Some non-CS PRNG like the Mersenne twister can achieve quite high a performance and be adequate in non-cryptographic situations where there is no intelligent attacker to defeat (e.g. physics simulations). Although there also are some known high-performance CSPRNG (e.g. these stream ciphers), a non-CS PRNG may give an edge in contexts where the lack of cryptographic security is not an issue.

-
so for CSPRNG we just process a seed with stream ciphers? where this seed come from? a PRNG?? (my question is more about implementation, what we have to do in code for security? i mean what is best secure way to ask a lib to give us a robust RN to process it with CSPRNG?) –  randomness Dec 18 '13 at 20:33
Sadly we actually had two separate questions suggesting your trivially broken example as a secure stream cipher. A simple block cipher based on the SHA-256 hash function and Is it feasible to build a stream cipher from a cryptographic hash function? –  CodesInChaos Dec 18 '13 at 20:45
just asking how to seed CSPRNG? a cipher can't generate random stat so we have to generate a seed first, where this seed come from and what we name it? –  randomness Dec 18 '13 at 20:54
Initial seed for a CSPRNG must come from something "which the attacker cannot know". Usually, this is "true randomness" extracted from hardware event. Typically, the system takes the time (down to the nanosecond, using the CPU cycle counter) at which hardware interrupts occurs, concatenates all these time values, and hashes the lot. Something similar occurs in the CSPRNG provided by usual operating systems (/dev/urandom on Linux, CryptGenRandom() on Windows...). –  Thomas Pornin Dec 18 '13 at 20:58