Our published paper takes a hard look at how older versions of the Jitter Entropy library perform its conditioning and filter its raw samples. The findings affect most existing JEnt-based ESV certificates. Here is the plain-language version.
If your product relies on the CPU Jitter Random Number Generator library (JEnt) for entropy, you have plenty of company. It ships in many Linux kernels and embedded platforms, and roughly two dozen certificates in the CMVP’s Entropy Source Validation (ESV) program are built on version 2.2.0 alone. That reach is why a paper published on September 15 by Joshua Hill (KeyPair Consulting) and Yvonne Cliff (Teron Labs), JEnt v2.2.0 LFSR Conditioning Analysis, is worth a few minutes of your time. Two presentations summarizing these results have already been provided to the CMVP and CMUF Entropy Working Group, accompanied by early drafts of the paper. The public release of this paper serves as a heads-up to vendors and labs.
A quick refresher
JEnt works by timing how long a small block of code takes to run, over and over. The tiny variations in those timings are measured and used as a source of entropy in the library. A conditioning component then mixes the raw samples into 64-bit output blocks.
JEnt v2.2.0, released in 2019 and still the version inside many kernels, used a linear feedback shift register (LFSR) as its conditioning component. Think of an LFSR as a simple bit-shuffling circuit. JEnt versions v3.0.0 and later replaced the LFSR conditioning with a hash function that NIST has pre-approved as “vetted” conditioners. The LFSR is not vetted, and SP 800-90B says a non-vetted conditioner needs mathematical evidence of how much entropy survives it. The paper’s starting point is that this evidence has never really existed for JEnt’s LFSR.
Two findings matter directly to vendors.
Finding 1: The LFSR keeps less entropy than the certificates say
Each output block from the v2.2.0 conditioner is built from 64 × osr raw samples. (The osr, or oversampling rate, is the knob your lab sets during validation to say how many raw samples are needed per output.) Many samples go in; 64 bits come out.
JEnt’s design documentation argued that an LFSR “does not diminish entropy.” That is true when you output as many bits as you put in. It is not true when you squeeze a large number of inputs into one output: some randomness is lost in the mixing. The paper builds an explicit model of this LFSR to measure the loss and arrives at a defensible claim of about 42.3 bits of entropy per 64-bit block.
Most existing JEnt v2.2.0 certificates claim between 56 and 60 bits per block. The paper shows that this range matches what NIST’s statistical test reports on any random-looking output, regardless of what went into it. In other words, the entropy numbers on the relevant ESV certificates appear to reflect the statistical test rather than an analysis of the conditioner. Under current CMVP guidance (IG D.K), the claim is supposed to be capped by the mathematical evidence, and by the paper’s analysis that cap is roughly a quarter lower than what most certificates state.
This is not a “your product is broken” finding. The output is still random-looking and still usable; a DRBG seeded from it would simply need more blocks to reach the same security strength. The is fundamentally an accounting finding, which is relevant within the ESV program.
Finding 2: The “stuck sample” filter may have skewed your osr
This finding is broader. It applies to JEnt v2.2.0 through v3.6.3, including the versions with the vetted hash conditioner.
Those versions check each raw sample to see whether it looks “stuck”: the same as the previous sample, or changing by the same amount as last time. Stuck samples are thrown away before conditioning. That sounds harmless, even prudent.
The paper’s point is that entropy is a property of the process, not of the data you happen to keep, and filtering changes the process. Its illustration: take a fair coin, one bit of entropy per flip, and throw away every flip that matches the one before it. What remains is a perfectly predictable heads-tails-heads-tails sequence with no entropy at all. The impact on real hardware is less extreme, but the effect is real and its size depends on the platform. Across twelve hardware and version combinations the authors tested, the filter discarded anywhere from 0.1% of samples (a server-class Xeon on JEnt v3.6.3) to 45% (an embedded ARM core on JEnt v2.2.0).
Here is the part that affects certificates. The osr on essentially every JEnt-based ESV certificate was set by analyzing the raw sample stream, before the filter. But the conditioner never sees that stream. It sees the filtered one, which can carry more or less entropy per sample than the raw stream, depending on the hardware. The paper does not claim that any specific certificate has the wrong osr. It says the osr was chosen against the wrong data, and that the exposure is greatest on embedded and mobile silicon and smallest on server x86.
A useful side result
To learn what “normal” looks like for NIST’s conditioned-output statistical test, the authors ran it a million times on ideal random data. Two takeaways for vendors: results above 59.885 bits per 64-bit block (the highest value that appears routinely) are rare enough, less than one validation in 3,500, that a lab or reviewer may reasonably ask how the dataset was chosen; and seeing that exact value, 59.885, on unrelated certificates is a quirk of one of NIST’s estimators, not a sign that anything is wrong.
What this means for the ESV program
The authors are careful to call their 42.3-bit figure a well-supported engineering estimate rather than a proof. Enforcement of the “mathematical evidence” requirement has been uneven over the program’s history. The CMVP has stated that they are working on new guidance to address the impact of health testing on the raw data entropy claim, but there is presently no draft text for this guidance publicly available.
What is reasonable to expect is that labs and CMVP reviewers will start asking two questions of JEnt-based submissions: What is the mathematical basis for your conditioned-output claim? (JEnt v2.2.0) and Was your osr set using post-filter data? (JEnt v2.2.0 through v3.6.3).
What you can do now
- Know your version. Confirm which JEnt version your product ships and whether it drops stuck samples. JEnt versions v2.2.0 through v3.6.3 do; v3.7.0 and later do not.
- Measure the filter. KeyPair’s open-source Theseus toolkit includes a utility (u32-jent-nonstuck) that produces the post-filter stream from a raw dataset,so you can see how much your hardware discards and test post-filtered data.
- For new products, use JEnt v3.7.0 or later. It feeds every sample to a vetted conditioner, which sidesteps both findings.
- If you are locked into an older version, the fix for the filter issue is a one-line change: keep the stuck check (JEnt still won’t count those samples as entropy), but feed them to the conditioner anyway, as v3.7.0 does. Your lab will need to know about the change.
- If you need a higher per-block claim on v2.2.0, the paper shows you can reach the 56–60 bit range by feeding roughly two to two-and-a-half times as many samples into each block, at a corresponding cost in how quickly entropy is produced.
- Talk to KeyPair Consulting or Teron Labs to learn more about the impacts of these findings on your design.
Read the paper
The full analysis, including the LFSR model, the measurements across twelve platforms, and the statistical characterization of NIST’s test, is available here: JEnt v2.2.0 LFSR Conditioning Analysis (v1.0, September 15, 2026). The authors’ landing page collects the paper, the presentation slides, the modeling code, and the raw test data.