3

NIST 800-90C defines 3 classes of random bit generation (RBG) constructions: RBG1, RBG2 and RBG3. All constructions must include a DRBG from NIST SP 800-90A. The particular construction in question is RBG3, which is "designed to provide output with a security strength equal to the requested length of its output by producing outputs that have full entropy" and is based on a physical entropy source. This construction has 2 types, RBG(XOR) and RBG(RS).

I am going to guess that "full entropy" is defined as entropy per bit above some threshold like 1-2^32 or 1-2^64, not sure what the actual threshold is here so please correct me.

Why does this recommendation require a RBG3 construction based on some physical entropy source to use a DRBG that is XOR'd or re-seeded by the entropy source to produce full entropy?

randumb20
  • 65
  • 4

2 Answers2

5

Why does this recommendation require a RBG3 construction based on some physical entropy source to use a DRBG that is XOR'd or re-seeded by the entropy source to produce full entropy?

Remember that RGB3 is designed for the ultraparanoid types, who ask if 1,000,000 random bits, want each of the $2^{1000000}$ possible outputs to be approximately equiprobable [1]. It should be obvious that this goal would be unachievable for any rng with a fixed state much less than 1,000,000 bits.

Hence, to output an arbitrary number of 'truly random' bits, we need some additional entropy inputs as we go along. NIST has opted for two different options to provide this additional entropy input; xor'ing the raw entropy input with the DRBG output, and periodic reseeding. The first option obviously achieves this goal (xor'ing a truly random string with anything not correlated to it produces a truly random string); the second one would appear to (if we make some plausible but unproven assumptions on the DRBG).

[1]: My opinion: don't ask me what they want to do with those random bits - almost all the uses of random bits use them as inputs to some computational complexity crypto, which would void any security we would get from informational theoretical randomness.

poncho
  • 154,064
  • 12
  • 239
  • 382
1

Allegedly, it comes from this:-

When n bits of output are requested from an RBG3(XOR) construction, n bits of output from the DRBG are XORed with n full-entropy bits obtained either directly from the entropy source or from the entropy source after cryptographic processing by an external vetted conditioning function (see Section 3.3). When the entropy source is working properly, an n-bit output from the RBG3(XOR) construction is said to provide n bits of entropy or to support a security strength of n bits. The DRBG used in the RBG3(XOR) construction is always required to support a 256-bit security strength. If the entropy source fails without being detected and the DRBG has been successfully instantiated with at least 256 bits of entropy, the DRBG continues to produce output at a security strength of 256 bits.

So if the entropy source fails (they don't if designed properly), you still have 256 bits of security strength XORed over the top of rubbish. XOR preserves entropy. Although if the source did fail, reseeding wouldn't really help if the DRBG is being fed with all zeros.

If the entropy source has failed though (without being detected) it may have failed on day one. So you'd be left with a NIST approved PRNG masquerading as a TRNG. I'd ignore virtually all of 800-90x and roll your own TRNG.

There is more sense in BSI AIS 20/31.

Paul Uszak
  • 15,905
  • 2
  • 32
  • 83