random: Allow pure entropy sources to provide a min-entropy estimate
ClosedPublic
Actions

Authored by markj on Aug 28 2025, 9:48 PM.

Details

Reviewers

Group Reviewers

Commits

rGb466df5ae9f8: random: Allow pure entropy sources to provide a min-entropy estimate
rGf865264f6a5e: random: Allow pure entropy sources to provide a min-entropy estimate

Summary

The current implementation of the NIST health tests assumes a
min-entropy estimate of one bit per sample, which is quite conservative.
For so-called "pure" sources (e.g., virtio-random, TPM) it might be nice
to support larger estimates so that the tests catch failed devices more
quickly.

Thus:

let each pure random source provide an estimate, so that downstreams can override defaults if they want to;
increase the default estimate for pure sources;
for pure sources initialize the state machine at source registration time.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 66623
Build 63506: arc lint + arc unit

Event Timeline

markj created this revision.Aug 28 2025, 9:48 PM

Herald added a subscriber: imp. · View Herald TranscriptAug 28 2025, 9:48 PM

markj requested review of this revision.Aug 28 2025, 9:48 PM

Harbormaster completed remote builds in B66623: Diff 161157.Aug 28 2025, 9:48 PM

Herald added a subscriber: obrien. · View Herald TranscriptAug 28 2025, 9:48 PM

markj added a parent revision: D52231: random.4: Document the kern.random.nist_healthtest_enabled tunable.Aug 28 2025, 9:48 PM

markj added a child revision: D52233: random: Exclude the timestamp from healthtest for pure sources.

8 bits per byte might be high for some sources... I'm not sure. It's probably fine for the relatively simplistic tests in the health test?

sys/dev/random/randomdev.h
106	This might also be interesting to Fortuna/etc for boot time min entropy estimation / initial seeding.

This revision is now accepted and ready to land.Aug 29 2025, 1:39 AM

In D52232#1193086, @cem wrote:

8 bits per byte might be high for some sources... I'm not sure. It's probably fine for the relatively simplistic tests in the health test?

Well, 8 bits per sample, but yes this might turn out to be excessive. Perhaps I should include a tunable to override that value.

In D52232#1193211, @markj wrote:

Well, 8 bits per sample, but yes this might turn out to be excessive. Perhaps I should include a tunable to override that value.

I guess I wouldn't expect any source to provide only one byte per sample, so that's only ~2 bits per byte at word-size input, which is not super high.

In D52232#1193347, @cem wrote:

In D52232#1193211, @markj wrote:

Well, 8 bits per sample, but yes this might turn out to be excessive. Perhaps I should include a tunable to override that value.

I guess I wouldn't expect any source to provide only one byte per sample, so that's only ~2 bits per byte at word-size input, which is not super high.