How to read a randomness claim without mistaking an attractive output for evidence about its source. Every device, dataset, audit log and numerical experiment below is hypothetical unless explicitly identified as a published source. The calculations are educational examples, not a generator design, a product assessment or a certification test. Sources checked October 30, 2026.
1. A passing score answers a narrower question
A page of green results can make a randomness claim look settled. The output contains roughly equal numbers of zeros and ones. Several tests found no unusual patterns. A chart looks noisy. None of those observations, alone, establishes that an adversary cannot predict the next value or that the source contributes the amount of uncertainty a cryptographic system requires.
NIST's April 2010 SP 800-22 publication explicitly warns that statistical testing cannot certify a generator's suitability for an application or replace cryptanalysis. Its April 19, 2022 revision decision goes further about the intended clarification: the revision would reject using that suite to assess cryptographic random-number generators. The current publication page still identifies the revision decision; this article does not treat that announcement as proof that a replacement edition has already been issued. SP 800-22 publication and warning; NIST's dated revision decision.
The distinction is not an argument against measurement. It is an argument for identifying what was measured. A test can detect a specified departure from a statistical model. A physical-source analysis can address why a device should produce uncertainty under particular conditions. A cryptographic analysis can examine whether a deterministic construction hides its internal state from a bounded adversary. Those are related tasks, but a result from one should not be silently promoted into a result from all three.
NIST finalized SP 800-90C on September 25, 2025. It addresses random-bit-generator constructions that combine mechanisms specified in SP 800-90A with randomness sources specified within the 800-90 framework, including entropy sources covered by SP 800-90B. This division of responsibilities is a useful warning against treating a test-suite name, a source claim and a complete generator construction as interchangeable credentials. NIST's final SP 800-90C record.
The practical questions begin before any test is run: What object is being evaluated? What can the observer know? Which conditions does the claim assume? How does raw source output become the bits an application receives? The worked examples below show why those questions can change the conclusion even when the displayed bitstream stays exactly the same.
2. Bit length is not the amount of uncertainty
A sixteen-bit field can represent 65,536 different values. That statement concerns its capacity, not the process that chooses its contents. A process that always writes the same value uses a sixteen-bit representation while offering no uncertainty to someone who knows the rule. A process that chooses uniformly among all possible values has a different distribution and a different guessing problem.
NIST and BSI's January 29, 2026 comparison report distinguishes Shannon entropy from min-entropy. For a discrete distribution, min-entropy is the negative base-two logarithm of the largest outcome probability; Shannon entropy averages the information associated with the possible outcomes. The report also stresses that credible entropy estimation requires understanding the underlying nondeterministic process, rather than relying only on black-box statistics. NIST IR 8446, entropy-estimation discussion.
Consider an invented source that chooses among four labels with probabilities one-half, one-quarter, one-eighth and one-eighth. The labels can be stored in two bits. The best single guess succeeds with probability one-half, so the distribution has one bit of min-entropy. Its Shannon entropy is 1.75 bits: the contributions are 0.5, 0.5, 0.375 and 0.375. Neither measure equals the two-bit storage width, and the two entropy measures do not equal each other.
Now consider a fictional biased binary source that produces one with probability 0.9 and zero with probability 0.1. Its min-entropy is about 0.152 bits per draw, while its Shannon entropy is about 0.469 bits per draw. These are calculations from stipulated probabilities, not estimates derived from observed hardware. Calling both numbers simply “entropy” would make a comparison ambiguous.
If one hundred draws are independent and identically distributed according to that stipulated biased model, the most likely full sequence is one hundred ones, with probability 0.9 raised to the hundredth power, about 0.00002656. The min-entropy of the complete sequence is therefore about 15.20 bits. The calculation multiplies because independence and the fixed distribution were explicitly assumed. It is not permission to multiply any reported per-sample estimate by an arbitrary output length.
That last distinction matters in a technical report. A statement about a single sample, a statement about an entire sequence and a rate expressed per output bit are different quantities. Before comparing two devices, determine which quantity each number describes and which assumptions connect it to the application's actual request.
3. Every position can look fair while the whole block has little uncertainty
A more surprising example removes the bias entirely. Imagine a fictional process that flips one fair coin at the beginning of a run, then writes the coin's result into all 128 positions of a block. Across repeated runs, every position is zero half the time and one half the time. Examined separately, each position has a fair marginal distribution.
The complete block, however, has only two possible values: all zeros or all ones. Each occurs with probability one-half. The block therefore has one bit of min-entropy, not 128. Once the first position is known, the remaining 127 positions are fixed by the stipulated rule. Adding the marginal uncertainties would count the same initial coin repeatedly.
This example is intentionally obvious to a visual observer. To separate appearance from the mathematical issue, replace the repeated block with a fixed public 128-bit mask. The process outputs either that mask or its bitwise complement, selected by one fair coin. Every position again has a fair marginal distribution across runs. The entire block still has only two possible outcomes. Whatever the mask looks like, the uncertainty in the selection remains one bit.
The example does not claim that these outputs pass a particular published test suite. No such test has been run, and a well-chosen test can detect the simple dependency. Its purpose is narrower: marginal balance does not imply joint independence. A table that reports only per-position frequencies leaves out a relationship that controls the uncertainty of the block.
For an audit, this suggests a concrete distinction between two evidence requests. “Show the proportion of ones” asks about a summary of observed values. “Explain the dependence structure across outputs” asks how observations constrain one another. A successful answer to the first does not automatically answer the second.
It also explains why rearranging a dataset is not a neutral operation for every question. If a report shuffles samples before analysis, it may preserve the count of zeros and ones while destroying the temporal structure needed to diagnose a dependency. The untouched sequence and the transformation should remain identifiable. Otherwise, a reader cannot determine whether the analysis examined the phenomenon that matters to the claim.
4. Ask what is uncertain to whom
Suppose an invented device chooses a uniformly random sixteen-bit value. Before any information is disclosed, all 65,536 values are equally possible. Now suppose its logging system publishes the first twelve bits and keeps only the remaining four secret. For someone who can read the log, sixteen candidates remain consistent with the disclosed prefix, and a best single guess succeeds with probability one-sixteenth.
Nothing about the original distribution changed. The observer's information changed. For every possible disclosed prefix in this example, the four remaining bits are still uniformly distributed, so the conditional calculation is simple and unambiguous. More complicated side-information models require more careful definitions; this example does not propose a general formula for every kind of conditional min-entropy.
A randomness report should therefore identify what information is excluded from the observer's knowledge. A source may be hard to predict from its output history alone while being easier to predict from another measurement. An audit that assumes a hidden parameter should say why that parameter is hidden in the actual setting. Merely omitting it from the analyst's dataset does not make it secret from everyone else.
Consider a second fictional packet containing identical output files for two operating modes. In one mode, an internal seed remains protected. In the other, a diagnostic record includes that seed. The output statistics can be identical while the security claim differs sharply. A test of the output file cannot establish which logging mode was active.
This is a reason to connect measurement records with system configuration, not to publish sensitive seeds. The public evidence can describe whether diagnostics were enabled, how secret-bearing logs were controlled and what the evaluation assumed, without exposing the secrets themselves. A raw dump of internal state would not be a responsible substitute for a clear assurance statement.
The question “random to whom?” also limits comparisons between laboratories. One evaluation may assume an observer sees only emitted bits; another may account for environmental measurements or partial state disclosure. Their numbers can differ because they answer different questions. Before declaring one result superior, align the information available to the modeled observer as well as the length and format of the output.
5. A sample frequency is not an exact source probability
Imagine collecting one thousand outputs from a binary source and observing exactly five hundred ones. The empirical proportion is 0.5. It does not follow that the true probability of a one is exactly 0.5, that the draws are independent, or that the distribution will remain unchanged tomorrow. Those are claims about the generating process, not merely descriptions of the observed file.
Under a stipulated model of one thousand independent fair draws, the probability of obtaining exactly five hundred ones is about 2.5225 percent. A fair source will therefore usually produce a count other than exactly five hundred. Treating perfect balance as a requirement would reject most samples from the very model the test was supposed to represent.
The same observed count is also possible under a stipulated independent model with a one probability of 0.52. For the exact five-hundred count, the likelihood under that model is about 0.449 times the likelihood under the fair model. This ratio compares how two specified models account for this particular observation. It is not the probability that either model is true, and it is not a complete entropy confidence interval.
The example exposes two opposite mistakes. One is to declare a generator defective because a finite sample is not perfectly balanced. The other is to declare it fully unpredictable because one finite sample happens to be balanced. Both treat a random observation as though it uniquely identifies the underlying process.
An evidence packet should distinguish the raw count, the model assumptions and the inference procedure. If an analyst reports a lower bound, the packet should explain how sampling uncertainty and dependence were treated. If the result is only a descriptive frequency, it should remain a descriptive frequency. Relabeling a point estimate as a certified lower bound does not add evidence.
Dataset selection matters as well. In a fictional experiment, suppose an analyst collects ten runs and publishes only the run closest to perfect balance. The displayed result is now conditioned on a selection rule. A reader who assumes it was the first unselected run is analyzing a different experiment. Preserve the inclusion rule and account for excluded data before interpreting the polished summary.
6. A conditioner can change representation without creating a new secret
RFC 5869 describes HKDF's extraction stage as concentrating existing entropy and explicitly states that it cannot amplify entropy. That is a statement about an input-output relationship, not a promise that any weak input becomes a strong secret merely because a familiar cryptographic function processes it. RFC 5869, application guidance.
Here is an original counting exercise that does not depend on a particular hash function. Suppose an invented deterministic mapping accepts one of 4,096 possible seed values and emits a 256-bit string. Once the mapping and seed are fixed, the output is fixed. There can be at most 4,096 different outputs reachable through those seeds, even though the output field has room for vastly more strings.
If the seeds are uniform and the mapping is one-to-one over those seeds, the output distribution has twelve bits of min-entropy. If some seeds collide to the same output, the largest output probability can increase and the min-entropy can be lower. The 256-bit display width does not change that counting argument. No actual cryptographic mapping was evaluated here, and the example is not a practical attack on a deployed system.
Now imagine an audit report that shows a visually irregular 256-bit sample and labels it “256 bits of entropy.” The report has skipped the distribution and the input process. To support that label, it would need evidence beyond the output width and appearance. In the fictional setup, the claim is incompatible with the stipulated number of possible seeds.
Conditioning can still serve important purposes. The analytical mistake is not using a deterministic function; it is confusing a more convenient or less biased representation with an increase in the uncertainty originally available. A complete claim needs to identify the input quantity, the transformation and the output quantity, including any additional independent randomness actually supplied.
This also clarifies what should be retained in a public technical description. It need not disclose secret values, but it should identify whether the evaluated samples came before or after conditioning. A dataset of conditioned outputs cannot simply be described as raw noise. The transformation may conceal the very source behavior that the evaluator needs to understand, even while producing output that is useful in a properly designed system.
7. Deterministic expansion is a different security claim
NIST SP 800-90A Revision 1 specifies deterministic random-bit-generation mechanisms based on cryptographic algorithms. Its discussion of prediction resistance distinguishes protection of future outputs after state compromise and explains the role of fresh entropy in reseeding. A long deterministic output and a fresh physical-entropy supply are therefore not the same object, even when the construction is appropriate for its intended cryptographic use. SP 800-90A Revision 1, mechanisms and prediction resistance.
An idealized example helps separate information-theoretic counting from computational difficulty. Suppose a protected seed is selected uniformly from a very large set and processed by a well-analyzed deterministic generator. The number of possible complete output streams is bounded by the possible initial states, but distinguishing the actual output from an ideal random stream may nevertheless be computationally infeasible within the stated security model. The counting observation alone does not show that a properly designed generator is insecure.
Conversely, invoking computational security does not repair an inadequately supported seed claim. The construction's assumptions still matter. If an evaluation presumes a seed drawn from one distribution while the actual source supplies a much narrower set, the implementation has not established the premise merely by using the named algorithm.
For a fictional audit, keep three records separate: the source's credited uncertainty, the generator's selected security-strength claim and the application's requested output length. A request for a million output bits does not mean the system collected a million fresh entropy bits for that request. Nor does a much shorter seed automatically mean the million-bit output is unsuitable. The question is what security property the construction provides under its actual seeding, state-protection and reseeding conditions.
A test plan should also distinguish a deterministic known-answer check from a source evaluation. Reproducing an expected result from specified test inputs can help check that an algorithm is implemented correctly. It does not establish that production inputs are unpredictable. The inputs in a known-answer exercise are deliberately controlled so that the result can be compared.
This is why a single headline number such as “bits generated per second” cannot summarize the assurance story. Output volume, source uncertainty, algorithmic security and state management require separate evidence. Combining them into one number obscures the conditions under which the system is supposed to remain secure.
8. Two sources do not automatically provide two independent contributions
Mixing multiple inputs can be useful, but the relationship between the inputs matters. RFC 4086 discusses mixing and cautions that expanding the output representation does not expand the unpredictability present in the inputs. Its historical discussion is relevant to that conceptual distinction; this article is not adopting its older algorithm-selection advice as a current implementation recommendation. RFC 4086, mixing and expansion.
Consider two invented one-bit inputs, X and Y, and combine them using exclusive-or, which outputs one when the inputs differ and zero when they match. In the first scenario, X and Y are independent fair bits. The four input pairs are equally likely. Two pairs produce zero and two produce one, so the output is fair.
In the second scenario, Y is an exact copy of X. Each input, considered separately across trials, is still a fair bit. But the pair is always either zero-zero or one-one, and the exclusive-or result is always zero. Two fair marginal distributions have produced a constant because the assumed independence was absent.
In the third scenario, Y is always the complement of X. Each input again looks fair by itself, but the exclusive-or result is always one. The lesson is not that exclusive-or is inherently bad. It is that the evidence about the relationship between inputs is part of the claim. Merely naming two sources does not establish independent uncertainty.
For a fictional device with two sensors, ask whether they share a clock, a physical influence, a control path or a common data buffer. Those questions do not prove harmful correlation, but they identify assumptions worth investigating. A diagram showing two boxes is not a measurement of their independence. Nor does collecting both streams into different files make them independent.
The audit should preserve enough timing and configuration information to test the asserted relationship. If the streams were collected on different days under different conditions, they may not represent the simultaneous joint process used by the deployed system. If one was derived from the other, the derivation belongs in the architecture description rather than being hidden behind separate component names.
9. Pooling conditions can hide a weak operating regime
Suppose an invented source operates in two clearly labeled conditions. During a warm regime it produces independent fair bits. During a cold regime it produces independent bits with a one probability of 0.9. Assume the regime schedule is known and the output behavior within each regime follows these stipulated models. These conditions are fictional and make no claim about any real sensor technology.
Collect nine thousand warm samples and one thousand cold samples. The expected overall fraction of ones is 0.54: half of the warm samples plus ninety percent of the cold samples, divided by the total. A summary that reports only this pooled fraction can make the source appear much less biased than it is during the cold period.
For a bit selected uniformly from the pooled positions without conditioning on its regime, the marginal min-entropy is about 0.889 bits, calculated from the largest probability, 0.54. For a bit known to come from the cold regime, it is about 0.152 bits. Neither number should be casually described as the entropy rate of the entire time-ordered process. They concern different random variables and different information.
Under the stronger assumptions stated here—known fixed counts and independent draws within and across regimes—the complete block's min-entropy can be calculated separately. The most likely block has probability 0.5 to the nine-thousandth power multiplied by 0.9 to the thousandth power. Its min-entropy is about 9,152 bits. That block calculation does not make the cold regime suitable for an application that specifically draws its secret during the cold interval.
An average can therefore answer the wrong operational question even when it is correctly computed. If the application asks for output immediately after a restart, a long steady-state dataset may not characterize the relevant period. If the evaluation excludes certain environmental conditions, the deployment claim should not silently include them.
For a public evidence review, look for the relationship between the tested conditions and the claimed operating range. A report need not release every proprietary detail to distinguish startup from steady operation, tested from untested conditions, or an observed result from an extrapolation. Those distinctions allow readers to judge the scope without pretending that an aggregate chart speaks for every mode.
10. Throughput accounting needs units at every step
A fictional interface emits one million samples per second, each stored in eight bits. Its raw data rate is eight million bits per second. Now stipulate that a justified model credits 0.25 bits of min-entropy per sample under conditions that permit the stated rate accounting. The credited fresh-entropy rate is 250,000 bits per second, not eight million.
The ratio is thirty-two to one between storage bits and credited entropy bits in this example. That ratio is not an efficiency judgment about a real device. It follows from the invented representation width and credited amount. A report that labels both rates simply “random bits per second” would conceal the distinction.
Suppose, solely for accounting, that a consumer requires 128 fresh entropy bits for each independent allocation and that there is no overhead or loss. Dividing 250,000 by 128 gives a long-run ceiling of about 1,953.125 such allocations per second. A fractional rate is meaningful as an average over time, not as a claim that a fraction of a request is completed during a particular second.
This is not a bound on all output from a deterministic generator seeded by that source. Such a generator can produce more output bits under a computational security claim. The accounting ceiling concerns the explicitly stipulated fresh-entropy allocation, not the speed of a cryptographic expansion algorithm. Changing which quantity is being measured changes the relevant denominator.
Now add a fictional queue of requests that arrives at two thousand allocations per second. Under the simplified fresh-allocation assumptions, demand exceeds the idealized supply by 46.875 allocations per second. A system cannot erase that mismatch by relabeling stored samples as full-entropy bits. It would need a different supported operating claim, a different allocation policy or additional resources; the arithmetic itself does not choose an implementation.
A credible performance statement therefore identifies the sample unit, credited uncertainty, conditions supporting the credit, transformation losses if applicable, and the output property being promised. Peak interface bandwidth and sustained assured service are different measurements. Their relationship should be shown, not inferred from the largest advertised number.
11. Health monitoring is about detecting failures, not certifying every output
SP 800-90B describes health tests on noise-source output before conditioning, including startup and continuous testing. Its discussion notes that resource-constrained continuous tests generally target gross failures and may allow some poor output before a failure is detected. A health-test result therefore should not be described as a mathematical certificate attached to each individual output bit. SP 800-90B, health-test discussion.
An invented alarm exercise shows why both sensitivity and false alarms matter. Suppose a test has a false-positive probability of one in a million for each specified evaluation window under the stipulated normal model. Across one million windows, the expected number of false alarms is one. This expectation follows by adding the probabilities; independence is not required for that expectation.
If the windows are additionally assumed independent, the probability of at least one false alarm is about 63.21 percent. The extra assumption is necessary for that particular calculation. Overlapping windows or shared state can change the relationship. A report that gives a per-window false-alarm probability without the number and dependence of windows leaves out information needed to interpret operational experience.
The opposite problem is missed failure. Imagine an invented fault that changes a source in a way the selected test rarely detects. A low false-alarm rate does not establish high detection probability for that fault. The evaluation must identify what kinds of failure were considered and how detection was assessed. One metric cannot substitute for the other.
The response path is also part of the evidence. In a fictional log, an alarm may be recorded correctly while the consuming application continues using output because it ignores the error status. The detector worked, but the wider system did not respond as the assurance argument assumed. Reviewing only the alarm counter would miss that connection.
These examples are not instructions for setting production thresholds. They show the information a reader needs to interpret a monitoring claim: the normal model, window definition, fault model, detection behavior and consumer response. Without those fields, “health tests passed” is too compressed to describe the relevant assurance.
12. Full entropy is a defined claim, not a synonym for looking noisy
NIST IR 8427 explains the full-entropy convention used in the 800-90 series. It discusses ideal entropy equal to a bitstring's length and the framework's assumption that a rate of at least one minus epsilon qualifies, with epsilon no greater than two to the minus thirty-second power. The report justifies that convention; it does not say that an arbitrary finite file with a favorable histogram has demonstrated it. NIST IR 8427 on the full-entropy assumption.
A label with this technical meaning should be traced to its supporting model and evaluation. In our earlier examples, a 256-bit output from only 4,096 equally possible seed values cannot acquire 256 bits of information-theoretic uncertainty merely through the label. The assumed distribution and mapping still determine the counting result.
This is also a reason to resist rounding away meaningful distinctions. A dashboard that displays two decimal places can show both 0.999 and 1.000 as 1.00, depending on the rounding rule. The display does not make the underlying values identical, and neither value by itself establishes compliance with a particular framework. Preserve the precision and definition needed for the actual claim rather than importing the dashboard's typography into the analysis.
There is a separate distinction between an estimated value and an accepted convention. A standard can define a threshold or an assumption for a construction. An evaluation must still establish why its inputs and conditions satisfy the applicable requirements. The existence of a definition is not evidence that a specific product meets it.
A useful public report can state the claimed property, the applicable document and version, and the evidence category supporting it. If the claim is only that a sample passed selected statistical tests, say that. If a source has undergone a particular validation, identify the validation's scope. Avoid using the same adjective to collapse these different levels of evidence.
13. Read a validation statement as a scoped record
NIST's current entropy-validation page describes the relationship between SP 800-90B documentation and cryptographic-module validation, and states that the program is accepting random-bit-generator submissions following publication of SP 800-90C. It points to an entropy-source validation search. The existence of a program, however, is distinct from the status of any particular implementation submitted to it. NIST's entropy-validation program information.
For an invented procurement review, suppose a vendor supplies a certificate for Source S, firmware version 2, evaluated in Configuration A. The proposed installation uses firmware version 3 in Configuration B. The certificate is a real-looking document within the exercise, but the supplied packet has not yet established that its scope covers the proposed installation. The reviewer should ask for the connection, not silently assume that a shared product name settles it.
That request need not become an accusation. A later version may be covered by additional documentation, or the apparent difference may not affect the relevant configuration. The point is to verify the relationship before making the assurance claim. Conversely, a vendor's statement that the change is minor is not itself the missing scope record.
Keep algorithm checks, entropy-source evaluation and whole-module validation distinct in the record. In the hypothetical packet, a successful test of a cryptographic primitive would not answer whether the noise-source model matches Configuration B. A source evaluation would not, by itself, establish that the application's error-handling path is correct. The names of the assessments should correspond to the questions they actually address.
A public-interest article can report this distinction without publishing confidential implementation details. It can identify the stated version, evaluated configuration and unresolved scope question, then explain what evidence would close the gap. That is more useful than either repeating a logo as a universal guarantee or dismissing all validation because it has boundaries.
The same discipline applies to dates. An evaluation's age is relevant to its context, but age alone does not prove failure. A recent marketing page is not necessarily a recent evaluation. Describe the actual document and any later evidence examined rather than substituting a vague claim that the product is either “certified” or “outdated.”
14. Reconcile an invented three-document evidence packet
Consider a final fictional case. Document A is a source report. It states that raw eight-bit samples were collected in steady operation under a specified environmental range and assigns the model-based credit used in section 10. Document B is a performance report showing a much higher rate of conditioned or expanded output. Document C is an application log showing restart events and occasional requests before the source-ready status was recorded.
The first reconciliation is between A and B. Their rates refer to different objects. A concerns source samples and credited fresh uncertainty; B concerns downstream output. They need not contradict each other, but B cannot be used as an independent measurement of A's fresh-entropy rate. The report should explain the transformation and security claim that connects them.
The second reconciliation is between A and C. A's steady-operation dataset does not directly characterize the pre-ready requests visible in C. That is a scope gap in the supplied packet. It does not prove that those requests received predictable output, because the case has not specified every possible fallback or state-management mechanism. It does establish that the cited source report alone does not answer the restart question.
The third reconciliation concerns the actual consumer. Suppose C records an error return but the application log shows the operation continued without recording which output path supplied its bytes. The next evidence request is specific: identify the path used for those operations and the assurance applicable to it. Repeating the steady-state benchmark would not resolve that missing link.
A narrow finding might read: “The supplied source evaluation addresses the stated steady-state configuration. The downstream throughput report measures a different output stage. The available logs do not establish which supported randomness path served requests during the identified restart interval.” This is an original hypothetical finding, not a description of a real vendor or breach.
Now suppose additional records show that the application blocked those requests until an independently supported source became ready. That evidence changes the conclusion about the restart interval. The reviewer should record the new connection and close the specific gap rather than retaining a suspicion after its factual basis has changed. Evidence review is not a contest to preserve either a favorable or an unfavorable first impression.
15. Keep the final claim smaller than the unsupported assumptions
A well-supported randomness statement names its object and conditions. It can distinguish a raw sample from a conditioned value, a marginal frequency from a joint distribution, and a model-based entropy credit from output length. It can explain what information the modeled observer has and which failure conditions the evaluation considered.
A weak statement replaces those fields with a slogan. “All tests passed” does not identify the tested hypotheses. “Quantum” does not identify the measured source model or its implementation boundaries. “256-bit” may describe storage width, a selected algorithm parameter or a security claim; the number needs its unit and meaning attached. None of these labels should be treated as self-explanatory evidence.
Standards themselves also have versions and corrections. NIST's SP 800-90B page carries a May 29, 2025 notice identifying two potential errata for a future update. The accompanying note explicitly distinguishes proposed corrections from an issued revised document. This article does not reuse the affected worked estimator example or present the notice as a new edition of the standard. SP 800-90B status and errata notice.
The practical value of the worked cases is that their conclusions can be checked. The biased coin's two entropy measures differ. The repeated block's fair marginals do not add to 128 independent bits. A public prefix reduces the remaining candidate set. A deterministic mapping cannot reach more outputs than its allowed inputs. A pooled operating average can conceal a weaker condition. A high output rate can coexist with a much lower fresh-entropy rate because the two rates describe different things.
Those are not objections to cryptography or to randomness testing. They are reasons to demand the right evidence for the right claim. A statistical test can be a useful observation within a larger evaluation. The mistake is letting that observation stand in for a source model, an implementation assessment and an account of what an adversary can know.
The next time a randomness result arrives as a polished scorecard, begin with one question: “What exactly does this result establish about the process that produced the bits?” The answer should lead to identifiable inputs, assumptions and records. If it leads only back to the appearance of the output, the central security question remains open.