Cryptographic applications use deterministic algorithm for random number generation that are not statistically random but they appears to be random.
Why do cryptographic applications use PRNGa instead of TRNGa?
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this communityCryptographic applications use deterministic algorithm for random number generation that are not statistically random but they appears to be random.
Why do cryptographic applications use PRNGa instead of TRNGa?
In many cryptographic systems, it's necessary for the two honest parties to have a shared secret between them such that:
For example, the one-time pad tells us that if two parties have a shared secret at least as large as the message, that is sufficient to communicate the message confidentially.
But the fatal problem then is, how do the parties manage to establish such large shared secrets? And the practical solution is to:
This is for example how stream ciphers work.
How do you build a true random number generator so that it's:
It's not easy at all! Cryptographically secure PRNGs are better in nearly all categories. Their only downside is that by definition they cannot truly random—but given a slow TRNG to provide seeds for the secure PRNG, that's a theoretical, not a practical downside.
Some of the techniques used in true RNGs are actually quite educational about the value of PRNGs. For example, one common technique in TRNGs is to XOR the TRNG's output with that of a PRNG. The reason for this is that way if the TRNG's true random components fail silently or are just not correct, the pseudorandom data mixed into the output can serve as a backup to keep the security level above a certain baseline.
That's an example of using a PRNG to address the engineering challenges of building a TRNG.
The cheapest secure solution for most applications is to use a slow source of true random data to periodically seed a secure PRNG. By allowing that source of true randomness to be very slow (produce random bits at a low rate), it makes all the engineering challenges easier. By using noise from peripherals that the computer already has (e.g., keyboard, mouse and network timings), it reduces the cost even more, and makes it easier for third parties to audit than a custom, proprietary device would.
The resulting system is not truly random, but it just needs to be good enough, not theoretically perfect.
Computers are simply incapable of generating true randomness because they are designed to be very accurate binary machines. Seeing as most cryptographic functions are implemented on computers they must settle for PRNG's
A Cryptographicaly secure PRNG has additional requirements that make it difficult for an attacker to guess the output if they know the seed, however they are all PRNG based. Examples of this might be to include mouse movement or key press timings in to the equation.
Random.org for example provides random numbers drawn from a variety of sources but if you use such an external source you then have to worry about the security of transporting numbers. Or you could start looking at hardware devices like this quantum device. This WIKI page goes over the hardware solutions in more depth.
You are correct to be worried about this because secure random number generation is at the heart of all modern crypto. If I could workout the random number you selected for a DH key exchange then TLS is broken.
There are many reasons for using a Computationally Secure PRNG. One of the most important reasons is probably that - as long as it is well seeded and if the state is well protected - a CSPRNG is very reliable.
One of the things that catches most people by surprise is the very high resistance against cycles (repeats of the internal state) of CSPRNG's.
A PRNG (or, to use another name, a DRBG) is very likely:
As already indicated you still need a source of entropy. It's very beneficial for this to be an on-chip TRNG with user available instructions, as you don't want to rely on other peripherals. For instance, if you have a VM or a headless device with SSD and high performance network card, you may not have too many reliable entropy sources.
However, once you have enough entropy - preferably from different sources - there is nothing wrong with using this to seed a PRNG. That way you can combine the security of all the entropy sources (and then remove most of the reliance on them).
Of course the reliability is not counting constructions such as the Dual-ECC generator that has likely been compromised by the NSA. Then again, how do you know that your hardware device is not compromised? The issue of compromise is also much less likely for hash based schemes.