Application of True Randomness generators in Cryptography

So the question is what is the True application of True Randomness in Cryptography?

You need “true randomness”—that is, a physical process whose outcome is hard enough to predict—to seed the pseudorandom generators that you use to generate keys for cryptography. Otherwise, you would have no secrets unknown to the adversary—you could try to keep your algorithms secret but that has been known since Kerckhoffs in the 19th century to be a fool's errand.

This is why essentially all modern application CPUs contain a hardware random source, such as Intel RDRAND/RDSEED or Arm RNDR/RNDRRS, backed by metastable flip-flops or jitter between parallel ring oscillators—to efficiently get an initial seed for the rest of your cryptography. But you can also seed your pseudorandom generators with die rolls or coin tosses, even if you don't have the patience of a 19th century professor of biology—100 d6 rolls is enough for 256 bits of entropy which is enough to defeat any adversary in the universe at a guessing game even in a multi-target attack. And then all your cryptography after that can be done with the PRG output.

Of course, if your PRG state leaks to the adversary, you need to draw an independent seed afresh from a physical process to prevent the adversary from breaking all your subsequent cryptography. (But, under reasonable designs like NIST SP 800-90Ar1 or anything else with backtracking resistance, past outputs are still safe from the adversary.)

For key stream generation the IVs or the seed keys are similarly expected to be chosen uniformly randomly.

That's right—and it is often hard to concoct a uniform distribution out of a physical process without feeding it through some mathematical cryptographic algorithm like SHA-256 to smooth out the distribution.

For example, even if you try to sample one bit at a time directly with uniform distribution by flipping a coin (and you do so honestly, for your own sake), it is biased to come up the way it started about 51% of the time—which may seem small, but it's likely plenty to admit a lattice attack like Howgrave–Graham on ECDSA signatures.

This is why modern hardware random sources are—in serious real-world applications (in contrast to kooks selling one-time pads to chumps)—fed through a conditioning component like AES-CMAC or SHA-256 or a Keccak sponge to generate kegs with indistinguishable-from-uniform distribution for cryptography.

But you still need to seed it all with an unpredictable physical process.

What is the exact application or True Randomness in Cryptography, either symmetric or public key?

TL;DR: TNRG's are mainly used as an entropy source for Deterministic Random Bit Generators (DRBG's), i.e. they are used for seeding and – where implemented – reseeding DRBG's. This kind of use is reflected in the design within Intel-based RDRAND (DRBG) and RDSEED (TRNG) instructions.

There is a very important and easy to make mistake in the question: a TRNG doesn't generate true randomness. That's a misleading term. The "true" in the term True Random Number Generator is about the generator not the output. It is, for instance, called a physical generator in AIS 31. The problem with the term "true" in TRNG is that novices often see it as the best generator to choose, while it often is not the one that they should use.

There are many problems with the direct appliance of TRNG's:

1. The entropy rate will not match the output rate, i.e. not every bit generated will have a bit of entropy.
2. The distribution may not be as close to uniform as expected / the source may have hidden bias.
3. It may be hard to validate that the TRNG is implemented as expected by the user, especially if certification bodies are not trusted by them.
4. And even if it is, errors within the TRNG may be hard to detect (though they may go through self-tests on startup).
5. A TRNG is a single source, which may require system access or system calls.
6. A TRNG may block or have latency and other performance-related issues if not enough entropy is available when called upon.
7. TRNG's may have other properties that are considered detrimental such as slow startup times (warm up times, self-tests etc.).
8. The TRNG or the communication with the TRNG may leak information to a listener or eavesdropper (more an issue if it is an external device, of course).
9. The TRNG may be malleable so that it doesn't produce valid random values anymore (again, mainly an issue if it is an external device and/or is dependent on external input).

Hence it is usually considered a more practical choice to use a DRBG that is seeded by a TRNG. Preferably it will also use other sources such as a random saved from the last use of the algorithm, entropy from hardware sources such as the Network Interface "Card" or NIC, CPU jitter, user input, a high-resolution timer, etc. This is the way that the "Linux DRBG" is constructed in modern kernels.

This does of course have the drawback that the randomness is not "true random" anymore, i.e. you cannot construct a theoretically secure OTP from a DRBG. However, as most DRBG's are generated from algorithms that are considered very strong this is generally considered to be a mostly theoretical issue; within a system it is unlikely to be the issue that will break security.

To be fair, there are issues with DRBG's as well of course:

1. The trust in the algorithm may not be warranted, e.g. Dual-EC DRBG.
2. It may be impossible to test or prove that the DRBG was well seeded (by the TRNG), especially on e.g. virtualized environments.
3. It still relies on the TRNG for seeding, or entropy from the CPU or outside sources.
4. The algorithm may expose unexpected statistical properties; some algorithms have a hard time within DieHard or similar testing.
5. If multiple seed sources are used it may take even more time to wait for them all to be available on startup.
6. A single seed source may be compromised and could be used to influence the output.

It is well known that the symmetric keys of encryption algorithms are supposed to be chosen randomly from the key space which has a large size so that any key is equally likely. This makes the brute force search to have largest search space. Similarly the private keys in public key schemes should also be uniformly random from the space of keys.

Correct.

For key stream generation the IVs or the seed keys are similarly expected to be chosen uniformly randomly. But in all these applications the keys to be chosen are of finite length. Hence True Randomness is not strictly applicable. Hence a high quality PR (Pseudo Randomness) is the only possible fast way to create randomness.

Seeds are seeds; they are not considered keys per se, even if they should be considered secret. They don't have a specified form and they aren't algorithm specific.

The size of the key or key stream doesn't matter. The term TRNG is used when the entropy within the output is directly retrieved from a physical source, possibly with a small amount of whitening applied to it to remove bias in the value of the bits.

The speed doesn't matter either; TRNG's that are integrated within chips can be really fast. They can rely on quantum-based properties, micro-fluctuations in calculations or time etc. Those kinds of properties can be read out really fast.

Note that the use of the term DRBG here is deliberate; it's more the definition that NIST uses, which includes aspects such as reseeding, i.e. the mixing in of additional entropy within the state of the algorithm. Those aspects are not always included when the term (Cryptographically Secure) Pseudo-Random Number Generator (CS)PRNG is used.

This doesn't mean that only NIST algorithms should be used; the answer just borrows the term. The designs of random number generators in operating systems for instance are often using the same techniques without directly using the NIST specified algorithms. Their design can be complex due to the different entropy sources used for seeding.