Why do we use pseudo random PRNG in cryptographic applications instead of true random number TRNG 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?
Expanding small shared secrets

In many cryptographic systems, it's necessary for the two honest parties to have a shared secret between them such that:


The attacker cannot easily guess it.
It's large enough to protect a large volume of data.


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:


Establish a small shared secret instead of a large one—say, 128 random bits—as the key.
Use a secure, deterministic PRNG to expand the key into a long, pseudorandom bit stream that's guaranteed to be the same on both sides.


This is for example how stream ciphers work.

Engineering challenges of TRNGs

How do you build a true random number generator so that it's:


Correct: Is the output actually random?  I.e., no bit of the output must be predictable from any other.  How do you prove this?  There are physical processes that science says are truly random, but does your machine introduce some predictable measurement errors into the system, and does your TRNG reliably remove these?
Reliable: Doesn't fail often, and when it does you can tell it did.
Auditable: The users can actually verify for themselves that it is correct and reliable.
Performant: Produces random bits at a sufficiently fast rate.
Efficient: Doesn't use lots of power.
Affordable: Doesn't cost a lot of money.


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.

Cost effectiveness

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.