All NIST SP 800-90B cite:[TuBaKe:18] required components and health test mechanisms must be implemented.

The entropy requirement is satisfied if 128 bits of full entropy can be obtained from each 256-bit (16*16 -bit) successful, but possibly non-consecutive entropy (ES16) output sequence using a vetted conditioning algorithm such as a cryptographic hash (See Section 3.1.5.1.1, SP 800-90B cite:[TuBaKe:18]). In practice, a min-entropy rate of 0.75 or larger is required for this.

Note that 128 bits of estimated input min-entropy does not yield 128 bits of conditioned, full entropy in SP 800-90B/C evaluation. Instead, the implication is that every 256-bit sequence should have min-entropy of at least 128+64 = 192 bits, as discussed in SP 800-90C cite:[BaKeRo:21]; the likelihood of successfully "guessing" an individual 256-bit output sequence should not be higher than 2^-192 even with (almost) unconstrained amount of entropy source data and computational power.

Rather than attempting to define all the mathematical and architectural properties that the entropy source must satisfy, we define that the physical entropy source be strong and robust enough to pass the equivalent of NIST SP 800-90 evaluation and certification for full entropy when conditioned cryptographically in ratio 2:1 with 128-bit output blocks.

Even though the requirement is defined in terms of 128-bit full entropy blocks, we recommend 256-bit security. This can be accomplished by using at least 512 entropy bits to initialize a DRBG that has 256-bit security.

For alternative Common Criteria certification (or self-certification), AIS 31 PTG.2 class cite:[KiSc11] (Sect. 4.3.) required hardware components and mechanisms must be implemented. In addition to AIS-31 PTG.2 randomness requirements (Shannon entropy rate of 0.997 as evaluated in that standard), the overall min-entropy requirement of remains, as discussed in NIST SP 800-90B / FIPS 140-3 Requirements. Note that 800-90B min-entropy can be significantly lower than AIS-31 Shannon entropy. These two metrics should not be equated or confused with each other.

A virtual source is not a physical entropy source but provides additional protection against covert channels, depletion attacks, and host identification in operating environments that can not be entirely trusted with direct access to a hardware resource. Despite limited trust, implementors should try to guarantee that even such environments have sufficient entropy available for secure cryptographic operations.

A virtual source traps access to the seed CSR, emulates it, or otherwise implements it, possibly without direct access to a physical entropy source. The output can be cryptographically secure pseudorandomness instead of real entropy, but must have at least 256-bit security, as defined below. A virtual source is intended especially for guest operating systems, sandboxes, emulators, and similar use cases.

As a technical definition, a random-distinguishing attack against the output should require computational resources comparable or greater than those required for exhaustive key search on a secure block cipher with a 256-bit key (e.g., AES 256). This applies to both classical and quantum computing models, but only classical information flows. The virtual source security requirement maps to Post-Quantum Security Category 5 cite:[NI16].

Any implementation of the seed CSR that limits the security strength shall not reduce it to less than 256 bits. If the security level is under 256 bits, then the interface must not be available.

A virtual entropy source does not need to implement WAIT or BIST states. It should fail (DEAD) if the host DRBG or entropy source fails and there is insufficient seeding material for the host DRBG.

Only basic arithmetic and slt* (for carry computations) are included. The data-independent timing requirement does not apply to HINT instruction encoding forms of these instructions.

Multiplication is included; division and remaindering excluded.

Same criteria as in RVI. Organised by quadrants.

All K-specific instructions are included. Additionally, seed CSR latency should be independent of ES16 state output entropy bits, as that is a sensitive security parameter. See ([crypto_scalar_es_access]) Security Considerations for Direct Hardware Access.

The Zbkb, Zbkc and Zbkx extensions are included in their entirety.

See cite:[riscv:bitmanip:draft] (Section 3.1.1) for details of these instructions.

The scalar cryptography extension provides the following instructions for manipulating the bit and byte endianness of data. They are all parameterisations of the Generalised Reverse with Immediate (grevi instruction. The scalar cryptography extension requires only the above instances of grevi be implemented, which can be invoked via their pseudo-ops.

The full specification of the grevi instruction is available in cite:[riscv:bitmanip:draft] (Section 2.2.2).

The zip and unzip pseudo-ops are specific instances of the more general shfli and unshfli instructions. The scalar cryptography extension requires only the above instances of [un]shfli be implemented, which can be invoked via their pseudo-ops. Only RV32 implementations require these instructions.

The full specification of the shfli instruction is available in cite:[riscv:bitmanip:draft] (Section 2.2.3).

See cite:[riscv:bitmanip:draft] (Section 2.6) for details of this instruction. See Data Independent Execution Latency Subset: Zkt for additional implementation requirements for these instructions, related to data independent execution latency.

See cite:[riscv:bitmanip:draft] (Section 2.1.3) for details of these instructions. These instructions are useful inside hash functions, block ciphers and for implementing software based side-channel countermeasures like masking. The andn instruction is also useful for constant time word-select in systems without the ternary Bitmanip cmov instruction.

See cite:[riscv:bitmanip:draft] (Section 2.1.4) for details of these instructions.

See cite:[riscv:bitmanip:draft] (Section 2.2.4) for a complete description of this instruction.

The xperm4 instruction operates on nibbles. GPR[rs1] contains a vector of XLEN/4 4-bit elements. GPR[rs2] contains a vector of XLEN/4 4-bit indexes. The result is each element in GPR[rs2] replaced by the indexed element in GPR[rs1], or zero if the index into GPR[rs2] is out of bounds.

The xperm8 instruction operates on bytes. GPR[rs1] contains a vector of XLEN/8 8-bit elements. GPR[rs2] contains a vector of XLEN/8 8-bit indexes. The result is each element in GPR[rs2] replaced by the indexed element in GPR[rs1], or zero if the index into GPR[rs2] is out of bounds.

Entropy sources are built by sampling and processing data from a noise source (Ring Oscillators). We will only consider physical sources of true randomness in this work. Since these are directly based on natural phenomena and are subject to environmental conditions (which may be adversarial), they require features that monitor the "health" and quality of those sources.

The requirements for physical entropy sources are specified in NIST SP 800-90B cite:[TuBaKe:18] (NIST SP 800-90B / FIPS 140-3 Requirements) for U.S. Federal FIPS 140-3 cite:[NI19] evaluations and in BSI AIS-31 cite:[KiSc01,KiSc11] (BSI AIS-31 PTG.2 / Common Criteria Requirements) for high-security Common Criteria evaluations. There is some divergence in the types of health tests and entropy metrics mandated in these standards, and RISC-V enables support for both alternatives.

Raw physical randomness (noise) sources are rarely statistically perfect, and some generate very large amounts of bits, which need to be "debiased" and reduced to a smaller number of bits. This process is called conditioning. A secure hash function is an example of a cryptographic conditioner. It is important to note that even though hashing may make any data look random, it does not increase its entropy content.

Non-cryptographic conditioners and extractors such as von Neumann’s "debiased coin tossing" cite:[Ne51] are easier to implement efficiently but may reduce entropy content (in individual bits removed) more than cryptographic hashes, which mix the input entropy very efficiently. However, they do not require cryptanalytic or computational hardness assumptions and are therefore inherently more future-proof. See Non-cryptographic Conditioners for a more detailed discussion.

Pseudorandom Number Generators (PRNGs) use deterministic mathematical formulas to create abundant random numbers from a smaller amount of "seed" randomness. PRNGs are also divided into cryptographic and non-cryptographic ones.

Non-cryptographic PRNGs, such as LFSRs and the linear-congruential generators found in many programming libraries, may generate statistically satisfactory random numbers but must never be used for cryptographic keying. This is because they are not designed to resist cryptanalysis; it is usually possible to take some output and mathematically derive the "seed" or the internal state of the PRNG from it. This is a security problem since knowledge of the state allows the attacker to compute future or past outputs.

Cryptographic PRNGs are also known as Deterministic Random Bit Generators (DRBGs), a term used by SP 800-90A cite:[BaKe15]. A strong cryptographic algorithm such as AES cite:[nist:fips:197] or SHA-2/3 cite:[nist:fips:202,nist:fips:180:4] is used to produce random bits from a seed. The secret seed material is like a cryptographic key; determining the seed from the DRBG output is as hard as breaking AES or a strong hash function. This also illustrates that the seed/key needs to be long enough and come from a trusted Entropy Source. The DRBG should still be frequently refreshed (reseeded) for forward and backward security.

The interface was designed to be simple so that a vendor- and device-independent driver component (e.g., in Linux kernel, embedded firmware, or a cryptographic library) may use seed to generate truly random bits.

An entropy source does not require a high-bandwidth interface; a single DRBG source initialization only requires 512 bits (256 bits of entropy), and DRBG output can be shared by any number of callers. Once initiated, a DRBG requires new entropy only to mitigate the risk of state compromise.

From a security perspective, it is essential that the side effect of flushing the secret entropy bits occurs upon reading. Hence we mandate a write operation on this particular CSR.

A blocking instruction may have been easier to use, but most users should be querying a (D)RBG instead of an entropy source. Without a polling-style mechanism, the entropy source could hang for thousands of cycles under some circumstances. A wfi ot pause mechanism (at least potentially) allows energy-saving sleep on MCUs and context switching on higher-end CPUs.

The reason for the particular OPST = seed[31:0] two-bit mechanism is to provide redundancy. The "fault" bit combinations 11 (DEAD) and 00 (BIST) are more likely for electrical reasons if feature discovery fails and the entropy source is actually not available.

The 16-bit bandwidth was a compromise motivated by the desire to provide redundancy in the return value, some protection against potential Power/EM leakage (further alleviated by the 2:1 cryptographic conditioning discussed in Cryptographic Conditioners), and the desire to have all of the bits "in the same place" on both RV32 and RV64 architectures for programming convenience.

SP 800-90C cite:[BaKeRo:21] states that each conditioned block of n bits is required to have n+64 bits of input entropy to attain full entropy. Hence NIST SP 800-90B cite:[TuBaKe:18] min-entropy assessment must guarantee at least 128 + 64 = 192 bits input entropy per 256-bit block ( cite:[BaKeRo:21], Sections 4.1. and 4.3.2 ). Only then a hashing of 16 * 16 = 256 bits from the entropy source will produce the desired 128 bits of full entropy. This follows from the specific requirements, threat model, and distinguishability proof contained in SP 800-90C cite:[BaKeRo:21], Appendix A. The implied min-entropy rate is 192/256=12/16=0.75. The expected Shannon entropy is much larger.

In FIPS 140-3 / SP 800-90 classification, an RBG2(P) construction is a cryptographically secure RBG with continuous access to a physical entropy source (seed) and output generated by a fully seeded, secure DRBG. The entropy source can also be used to build RBG3 full entropy sources cite:[BaKeRo:21]. The concatenation of output words corresponds to the Get_ES_Bitstring function.

The 128-bit output block size was selected because that is the output size of the CBC-MAC conditioner specified in Appendix F of cite:[TuBaKe:18] and also the smallest key size we expect to see in applications.

If NIST SP 800-90B certification is chosen, the entropy source should implement at least the health tests defined in Section 4.4 of cite:[TuBaKe:18]: the repetition count test and adaptive proportion test, or show that the same flaws will be detected by vendor-defined tests.

PTG.2 is one of the security and functionality classes defined in BSI AIS 20/31 cite:[KiSc11]. The PTG.2 source requirements work as a building block for other types of BSI generators (e.g., DRBGs, or PTG.3 TRNG with appropriate software post-processing).

For validation purposes, the PTG.2 requirements may be mapped to security controls T1-3 (Security Controls and Health Tests) and the interface as follows:

Note how P7 concerns Shannon entropy, not min-entropy as with NIST sources. Hence the min-entropy requirement needs to be also stated. PTG.2 modules built and certified to the AIS-31 standard can also meet the "full entropy" condition after 2:1 cryptographic conditioning, but not necessarily so. The technical validation process is somewhat different.

All sources that are not direct physical sources (meeting the SP 800-90B or the AIS-31 PTG.2 requirements) need to meet the security requirements of virtual entropy sources. It is assumed that a virtual entropy source is not a limiting, shared bandwidth resource (but a software DRBG).

DRBGs can be used to feed other (virtual) DRBGs, but that does not increase the absolute amount of entropy in the system. The entropy source must be able to support current and future security standards and applications. The 256-bit requirement maps to "Category 5" of NIST Post-Quantum Cryptography (4.A.5 "Security Strength Categories" in cite:[NI16]) and TOP SECRET schemes in Suite B and the newer U.S. Government CNSA Suite cite:[NS15].

The ISA implementation and system design must try to ensure that the hardware-software interface minimizes avenues for adversarial information flow even if not explicitly forbidden in the specification.

For security, virtualization requires both conditioning and DRBG processing of physical entropy output. It is recommended if a single physical entropy source is shared between multiple different virtual machnies or if the guest OS is untrusted. A virtual entropy source is significantly more resistant to depletion attacks and also lessens the risk from covert channels.

The direct mseccfg.[s,u]seed option allows one to draw a security boundary around a component in relation to Sensitive Security Parameter (SSP) flows, even if that component is not in M mode. This is helpful when implementing trusted enclaves. Such modules can enforce the entire key lifecycle from birth (in the entropy source) to death (zeroization) to occur without the key being passed across the boundary to external code.

Depletion. Active polling may deny the entropy source to another simultaneously running consumer. This can (for example) delay the instantiation of that virtual machine if it requires entropy to initialize fully.

Covert Channels. Direct access to a component such as the entropy source can be used to establish communication channels across security boundaries. Active polling from one consumer makes the resource unavailable WAIT instead of ES16 to another (which is polling infrequently). Such interactions can be used to establish low-bandwidth channels.

Hardware Fingerprinting. An entropy source (and its noise source circuits) may have a uniquely identifiable hardware "signature." This can be harmless or even useful in some applications (as random sources may exhibit Physically Un-clonable Function (PUF) -like features) but highly undesirable in others (anonymized virtualized environments and enclaves). A DRBG masks such statistical features.

Side Channels. Some of the most devastating practical attacks against real-life cryptosystems have used inconsequential-looking additional information, such as padding error messages cite:[BaFoKa:12] or timing information cite:[MoSuEi:20].

We urge implementers against creating unnecessary information flows via status or custom bits or to allow any other mechanism to disable or affect the entropy source output. All information flows and interaction mechanisms must be considered from an adversarial viewpoint: the fewer the better.

As an example of side-channel analysis, we note that the entropy polling interface is typically not "constant time." One needs to analyze what kind of information is revealed via the timing oracle; one way of doing it is to model seed as a rejection sampler. Such a timing oracle can reveal information about the noise source type and entropy source usage, but not about the random output entropy bits themselves. If it does, additional countermeasures are necessary.

A sequence of simple tests is invoked via resetting, rebooting, or powering up the hardware (not an ISA signal). The implementation will simply return BIST during the initial start-up self-test period; in any case, the driver must wait for them to finish before starting cryptographic operations. Upon failure, the entropy source will enter a no-output DEAD state.

Rationale. Interaction with hardware self-test mechanisms from the software side should be minimal; the term "on-demand" does not mean that the end-user or application program should be able to invoke them in the field (the term is a throwback to an age of discrete, non-autonomous crypto devices with human operators).

If an error is detected in continuous tests or environmental sensors, the entropy source will enter a no-output state. We define that a non-critical alarm is signaled if the entropy source returns to BIST state from live (WAIT or ES16) states. Critical failures will result in DEAD state immediately. A hardware-based continuous testing mechanism must not make statistical information externally available, and it must be zeroized periodically or upon demand via reset, power-up, or similar signal.

Rationale. Physical attacks can occur while the device is running. The design should avoid guiding such active attacks by revealing detailed status information. Upon detection of an attack, the default action should be aimed at damage control — to prevent weak crypto keys from being generated.

The statistical nature of some tests makes "type-1" false positives a possibility. There may also be requirements for signaling of non-fatal alarms; AIS 31 specifies "noise alarms" that can go off with non-negligible probability even if the device is functioning correctly; these can be signaled with BIST. There rarely is anything that can or should be done about a non-fatal alarm condition in an operator-free, autonomous system.

The state of statistical runtime health checks (such as counters) is potentially correlated with some secret keying material, hence the zeroization requirement.

Since the security of most cryptographic operations depends on the entropy source, a system-wide "default deny" security policy approach is appropriate for most entropy source failures. A hardware test failure should at least result in the DEAD state and possibly reset/halt. It’s a show stopper: The entropy source (or its cryptographic client application) must not be allowed to run if its secure operation can’t be guaranteed.

Rationale. These tests can complement other integrity and tamper resistance mechanisms (See Chapter 18 of cite:[An20] for examples).

Some hardware random generators are, by their physical construction, exposed to relatively non-adversarial environmental and manufacturing issues. However, even such "innocent" failure modes may indicate a fault attack cite:[KaScVe13] and therefore should be addressed as a system integrity failure rather than as a diagnostic issue.

Security architects will understand to use permanent or hard-to-recover "security-fuse" lockdowns only if the threshold of a test is such that the probability of false-positive is negligible over the entire device lifetime.

Some of the most devastating practical attacks against real-life cryptosystems have used inconsequential-looking additional information, such as padding error messages cite:[BaFoKa:12] or timing information cite:[MoSuEi:20]. In cryptography, such out-of-band information sources are called "oracles."

To guarantee that no sensitive data is read twice and that different callers don’t get correlated output, it is required that hardware implements wipe-on-read on the randomness pathway during each read (successful poll). For the same reasons, only complete and fully processed random words shall be made available via entropy (ES16 status of seed).

This also applies to the raw noise source. The raw source interface has been delegated to an optional vendor-specific test interface. Importantly the test interface and the main interface should not be operational at the same time.

An entropy source is a singular resource, subject to depletion and also covert channels cite:[EvPo16]. Observation of the entropy can be the same as the observation of the noise source output, as cryptographic conditioning is mandatory only as a post-processing step. SP 800-90B and other security standards mandate protection of noise bits from observation and also influence.

We will give some examples of common noise sources that can be implemented in the processor itself (using standard cells).

The most common entropy source type in production use today is based on "free running" ring oscillators and their timing jitter. Here, an odd number of inverters is connected into a loop from which noise source bits are sampled in relation to a reference clock cite:[BaLuMi:11]. The sampled bit sequence may be expected to be relatively uncorrelated (close to IID) if the sample rate is suitably low cite:[KiSc11]. However, further processing is usually required.

AMD cite:[AM17], ARM cite:[AR17], and IBM cite:[LiBaBo:13] are examples of ring oscillator TRNGs intended for high-security applications.

There are related metastability-based generator designs such as Transition Effect Ring Oscillator (TERO) cite:[VaDr10]. The differential/feedback Intel construction cite:[HaKoMa12] is slightly different but also falls into the same general metastable oscillator-based category.

The main benefits of ring oscillators are: (1) They can be implemented with standard cell libraries without external components — and even on FPGAs cite:[VaFiAu:10], (2) there is an established theory for their behavior cite:[HaLe98,HaLiLe99,BaLuMi:11], and (3) ample precedent exists for testing and certifying them at the highest security levels.

Ring oscillators also have well-known implementation pitfalls. Their output is sometimes highly dependent on temperature, which must be taken into account in testing and modeling. If the ring oscillator construction is parallelized, it is important that the number of stages and/or inverters in each chain is suitable to avoid entropy reduction due to harmonic "Huyghens synchronization" cite:[Ba86]. Such harmonics can also be inserted maliciously in a frequency injection attack, which can have devastating results cite:[MaMo09]. Countermeasures are related to circuit design; environmental sensors, electrical filters, and usage of a differential oscillator may help.

A category of random sources consisting of discrete events and modeled as a Poisson process is called "shot noise." There’s a long-established precedent of certifying them; the AIS 31 document cite:[KiSc11] itself offers reference designs based on noisy diodes. Shot noise sources are often more resistant to temperature changes than ring oscillators. Some of these generators can also be fully implemented with standard cells (The Rambus / Inside Secure generic TRNG IP cite:[Ra20] is described as a Shot Noise generator).

It may be possible to certify more exotic noise sources and designs, although their stochastic model needs to be equally well understood, and their CPU interfaces must be secure. See Quantum vs. Classical Random for a discussion of Quantum entropy sources.

Health monitoring requires some state information related to the noise source to be maintained. The tests should be designed in a way that a specific number of samples guarantees a state flush (no hung states). We suggest flush size W =< 1024 to match with the NIST SP 800-90B required tests (See Section 4.4 in cite:[TuBaKe:18]). The state is also fully zeroized in a system reset.

The two mandatory tests can be built with minimal circuitry. Full histograms are not required, only simple counter registers: repetition count, window count, and sample count. Repetition count is reset every time the output sample value changes; if the count reaches a certain cutoff limit, a noise alarm (BIST) or failure (DEAD) is signaled. The window counter is used to save every W’th output (typically W in { 512, 1024 }). The frequency of this reference sample in the following window is counted; cutoff values are defined in the standard. We see that the structure of the mandatory tests is such that, if well implemented, no information is carried beyond a limit of W samples.

Section 4.5 of cite:[TuBaKe:18] explicitly permits additional developer-defined tests, and several more were defined in early versions of FIPS 140-1 before being "crossed out." The choice of additional tests depends on the nature and implementation of the physical source.

Especially if a non-cryptographic conditioner is used in hardware, it is possible that the AIS 31 cite:[KiSc11] online tests are implemented by driver software. They can also be implemented in hardware. For some security profiles, AIS 31 mandates that their tolerances are set in a way that the probability of an alarm is at least 10^-6 yearly under "normal usage." Such requirements are problematic in modern applications since their probability is too high for critical systems.

There rarely is anything that can or should be done about a non-fatal alarm condition in an operator-free, autonomous system. However, AIS 31 allows the DRBG component to keep running despite a failure in its Entropy Source, so we suggest re-entering a temporary BIST state (Security Controls and Health Tests) to signal a non-fatal statistical error if such (non-actionable) signaling is necessary. Drivers and applications can react to this appropriately (or simply log it), but it will not directly affect the availability of the TRNG. A permanent error condition should result in DEAD state.

As noted in Conditioning: Cryptographic and Non-Cryptographic, physical randomness sources generally require a post-processing step called conditioning to meet the desired quality requirements, which are outlined in Entropy Source Requirements.

The approach taken in this interface is to allow a combination of non-cryptographic and cryptographic filtering to take place. The first stage (hardware) merely needs to be able to distill the entropy comfortably above the necessary level.

Note that the hardware may also implement a full cryptographic conditioner in the entropy source, even though the software driver still needs a cryptographic conditioner, too (Entropy Source Requirements).

Rationale: The main advantage of non-cryptographic extractors is in their energy efficiency, relative simplicity, and amenability to mathematical analysis. If well designed, they can be evaluated in conjunction with a stochastic model of the noise source itself. They do not require computational hardness assumptions.

For secure use, cryptographic conditioners are always required on the software side of the ISA boundary. They may also be implemented on the hardware side if necessary. In any case, the entropy ES16 output must always be compressed 2:1 (or more) before being used as keying material or considered "full entropy."

Examples of cryptographic conditioners include the random pool of the Linux operating system, secure hash functions (SHA-2/3, SHAKE cite:[nist:fips:202,nist:fips:180:4]), and the AES / CBC-MAC construction in Appendix F, SP 800-90B cite:[TuBaKe:18].

In some constructions, such as the Linux RNG and SHA-3/SHAKE cite:[nist:fips:202] based generators, the cryptographic conditioning and output (DRBG) generation are provided by the same component.

Rationale: For many low-power targets constructions the type of hardware AES CBC-MAC conditioner used by Intel cite:[Me18] and AMD cite:[AM17] would be too complex and energy-hungry to implement solely to serve the seed CSR. On the other hand, simpler non-cryptographic conditioners may be too wasteful on input entropy if high-quality random output is required — (ARM TrustZone TRBG cite:[AR17] outputs only 10Kbit/sec at 200 MHz.) Hence a resource-saving compromise is made between hardware and software generation.

All random bits reaching end users and applications must come from a cryptographic DRBG. These are generally implemented by the driver component in software. The RISC-V AES and SHA instruction set extensions should be used if available since they offer additional security features such as timing attack resistance.

Currently recommended DRBGs are defined in NIST SP 800-90A (Rev 1) cite:[BaKe15]: CTR_DRBG, Hash_DRBG, and HMAC_DRBG. Certification often requires known answer tests (KATs) for the symmetric components and the DRBG as a whole. These are significantly easier to implement in software than in hardware. In addition to the directly certifiable SP 800-90A DRBGs, a Linux-style random pool construction based on ChaCha20 cite:[Mu20] can be used, or an appropriate construction based on SHAKE256 cite:[nist:fips:202].

These are just recommendations; programmers can adjust the usage of the CPU Entropy Source to meet future requirements.

A Quantum Random Number Generator (QRNG) is a TRNG whose source of randomness can be unambiguously identified to be a specific quantum phenomenon such as quantum state superposition, quantum state entanglement, Heisenberg uncertainty, quantum tunneling, spontaneous emission, or radioactive decay cite:[IT19].

Direct quantum entropy is theoretically the best possible kind of entropy. A typical TRNG based on electronic noise is also largely based on quantum phenomena and is equally unpredictable - the difference is that the relative amount of quantum and classical physics involved is difficult to quantify for a classical TRNG.

QRNGs are designed in a way that allows the amount of quantum-origin entropy to be modeled and estimated. This distinction is important in the security model used by QKD (Quantum Key Distribution) security mechanisms which can be used to protect the physical layer (such as fiber optic cables) against interception by using quantum mechanical effects directly.

This security model means that many of the available QRNG devices do not use cryptographic conditioning and may fail cryptographic statistical requirements cite:[HuHe20]. Many implementers may consider them to be entropy sources instead.

Relatively little research has gone into QRNG implementation security, but many QRNG designs are arguably more susceptible to leakage than classical generators (such as ring oscillators) as they tend to employ external components and mixed materials. As an example, amplification of a photon detector signal may be observable in power analysis, which classical noise-based sources are designed to resist.

PQC public-key cryptography standards cite:[NI16] do not require quantum-origin randomness, just sufficiently secure keying material. Recall that cryptography aims to protect the confidentiality and integrity of data itself and does not place any requirements on the physical communication channel (like QKD).

Classical good-quality TRNGs are perfectly suitable for generating the secret keys for PQC protocols that are hard for quantum computers to break but implementable on classical computers. What matters in cryptography is that the secret keys have enough true randomness (entropy) and that they are generated and stored securely.

Of course, one must avoid DRBGs that are based on problems that are easily solvable with quantum computers, such as factoring cite:[Sh94] in the case of the Blum-Blum-Shub generator cite:[BlBlSh86]. Most symmetric algorithms are not affected as the best quantum attacks are still exponential to key size cite:[Gr96].

As an example, the original Intel RNG cite:[Me18], whose output generation is based on AES-128, can be attacked using Grover’s algorithm with approximately square-root effort cite:[JaNaRo:20]. While even "64-bit" quantum security is extremely difficult to break, many applications specify a higher security requirement. NIST cite:[NI16] defines AES-128 to be "Category 1" equivalent post-quantum security, while AES-256 is "Category 5" (highest). We avoid this possible future issue by exposing direct access to the entropy source which can derive its security from information-theoretic assumptions only.