A True Random Number Generator uses a physical phenomenon not known to be fully deterministic as origin of the discrete values (bits or integer numbers) that it outputs. That phenomenon can for example be a dice throw, thermal noise, disintegration of a radioactive substance… What detects this phenomenon can be followed by a conditioning stage to turn the output into an (at least, near) ideal sequence of random bits. The conditioning is often an integral part of the TRNG.
The archetypal conditioning stage is the Von Neumann debiaser: it groups the values at its input (such as dice values, binary output of a clocked comparator, count of clock cycles between events…) into pairs, and outputs 0, nothing, or 1, depending on if the first element in the pair is less, equal or more than the second. If the input was consisting of independent values, the output (if any) would be independent random bits with 50% probability for 0 and for 1; that is, truly uniform independent random bits (hereafter: ideal randomness).
Unless otherwise stated, a TRNG can be imperfect to some degree: it is to be expected that a statistical test distinguishes its output from ideal randomness.
A Cryptographically Secure Pseudo Random Number Generator is a deterministic (hence the pseudo) computational method to turn an input (typically short or low-throughput, and explicit unless otherwise stated) into a (typically arbitrarily long or/and high-throughput) sequence of bits that are indistinguishable from ideal randomness, with cryptographic certainty, for a computationally bounded adversary not knowing the input, assumed secret and not reused.
In a cryptographic context, a CSPRNG can be abbreviated PRNG or PRG. But in other contexts, not all PRNGs are cryptographically secure. The Mersenne Twister is an example of PRNG that is not cryptographically secure.
A Cryptographically Secure Random Number Generator (not Pseudo) is a random generator with no explicit input, and which output is indistinguishable from ideal randomness, with cryptographic certainty, for a computationally bounded adversary assumed able to attack multiple instances of the CSRNG and obtain multiple output sequences (the adversary can use one CSRNG to attack another; restart the CSRNG, in some attack model s/he can attempt to exploit side channels, inject faults in the calculations made, or/and shutdown power at any time).
The archetypal deterministic CSRNG is built from a CSPRNG and a random secret seed that is not reused (perhaps, with help of permanent memory surviving a power cycle). That is essentially the only way to build a CSRNG without some form of TRNG.
The archetypal non-deterministic CSRNG is built from a CSPRNG, and a TRNG which output is used as input of the CSPRNG at start of each sequence (including power-up). The idea is that the cryptographic strength of the CSRNG comes mainly from the CSPRNG, and the unpredictability across multiple sequences and instances comes from the TRNG.
Note: there are more complex constructions, where the TRNG's output influences the CSRNG continuously, so that hopefully, security will eventually be recovered after a compromise of the CSPRNG state. A Unix /dev/urandom typically uses this strategy.
A TRNG can be a CSRNG. Any CSRNG must include a TRNG, or must have made use of one as the origin of some secret value at an initialization stage (otherwise, knowledge of the CSRNG structure would allow to predict its output).
It is notoriously difficult to make a good non-deterministic CSRNG even by applying the above principle and using a good CSPRNG. One reason is that in practice, TRNGs often fail, spontaneously or under adversarial influence (for example, an adversary can reduce thermal noise by putting the device in cold condition using evaporation of some liquefied gas, or remotely feed controlled events to a sensor of disintegration). If that goes undetected, the output of the TRNG can become highly predictable, and knowledge of the PRNG will allow to predict its output. Thus a practical non-deterministic CSRNG must test its TRNG, and somewhat prevent any output when it does not operate properly.
On the other hand, a deterministic CSRNG must permanently keep its state secret. Due to the possibility of side channels attacks that's difficult when the adversary has physical access, and it turns out that methods to guard against side-channel attacks require random numbers in vast quantity! Also, there is understandable prevention against fully deterministic RNGs. This adds up to make fully deterministic CSRNGs a rarity in modern high-security cryptographic designs.
Summary of terminology:
- A TRNG is not deterministic. Unless otherwise stated, that's its only defining characteristic.
- A CSPRNG is deterministic, has an explicit input (unless otheriwse stated), and, with cryptographic certainty, its output is indistinguishable from ideal randomness by a computationally bounded adversary if its input is random, secret, and not reused.
- A CSRNG has no explicit input, at least appears not deterministic, and its output is computationally indistinguishable from ideal randomness by a computationally bounded adversary. It can be deterministic, or not. In the former case, it's a CSPRNG with a random secret key that is not reused. In the later case, it includes (or perhaps is) a TRNG.
- In a cryptographic context, PRNG or just PRG is synonymous with CSPRNG, and RNG might be synonymous with CSRNG (especially when using a RNG in another construct, rather than discussing its properties). But in non-cryptographic contexts, don't assume any security property from the acronym PRNG: in many programming languages, the default implementation is not cryptographically secure.
If they (TRNG and CSPRNG) are both non-deterministic are they not the same? Are they not both producing unpredictable outputs?
A CSPRNG is deterministic, and never is a TRNG; and vice versa.
Do we not use both TRNG and CSPRNG to produce sessions keys?
Often we use a CSPRNG initialized with a shared secret and some other element (like a nonce) to initialize session keys, so that the session keys needs not be transmitted secretly.
If we use the output of a CSRNG or TRNG as a session key, we need to encipher the value produced on one side to transfer it to the other side, which has no way to produce the same session key independently. Further, it we use a TRNG directly, we must use one that is close enough to a CSRNG that the key can't be guessed (that's an issue for short keys).
Another practice is to use a CSRNG or TRNG (often, one on each side) as input to an asymmetric key exchange protocol (like Diffie-Hellman) to produce a shared secret session key.
Can we (do we?) use TRNG to produce CSPRNG?
No. But we often use a TRNG and a CSPRNG to produce a CSRNG.