A software entropy source, built toward certification — not just a claim.

Entropy used to be asserted. Now it has to be proven.

NIST Special Publication 800-90B has required formal characterization, testing, and justification of entropy sources for every FIPS 140 submission since November 2020 — not merely a claim that a source is "random enough." Historical incidents involving predictable key generation have shown entropy failures are exploited in practice, not theoretical.

Three linked NIST documents govern random bit generation.

Entropy sources can't be self-certified. Testing runs through a laboratory holding NVLAP 17ESV accreditation, which submits raw noise samples and design documentation to NIST's Cryptographic Module Validation Program via the Entropy Source Validation Test System — which then issues (or returns for revision) a public ESV certificate.

The incumbent's asset is the certificate. That's exactly where we compete.

SafeLogic's CryptoComply Entropy Provider (CCEP) is the most visible commercial, standalone, ESV-certified software entropy source today — ESV Certificate #E241, shipping as a native OpenSSL 3.x provider (3.0 through 3.5), certified across 16 Operating Environments at launch. It demonstrates real market demand. It also leaves clear gaps we're building toward.

Comparison based on SafeLogic's public product documentation as of July 2026.

A timing-jitter noise source, with continuous health tests already implemented.

The prototype belongs to the well-established family of CPU/timer-jitter software entropy sources. Between two executions of a fixed, data-dependent workload, elapsed time is measured on the highest-resolution monotonic clock available — and because that elapsed time is shaped by cache state, memory bus contention, branch prediction, interrupts, and OS scheduling jitter, the low-order bits of the timing delta serve as the raw noise output.

SP 800-90B §4.4 requires continuous, in-line health testing during normal operation, not just pre-certification characterization. The prototype implements both default tests: the Repetition Count Test, which alarms when a sample value repeats too many times in a row, and the Adaptive Proportion Test, which alarms when a reference value reappears too often within a sliding window. Both cutoffs are currently conservative placeholders — per SP 800-90B, they must be recalculated from the validated min-entropy estimate, not assumed in advance.

// Core raw-sample generation — illustrative excerpt
static uint8_t get_raw_noise_byte(uint64_t *state) {
    uint8_t out = 0;
    for (int fold = 0; fold < 4; fold++) {
        uint64_t t0 = monotonic_ns();
        *state = jitter_workload(*state);
        uint64_t t1 = monotonic_ns();
        uint64_t delta = t1 - t0;
        out ^= (uint8_t)(delta & 0xFF);
        out = (uint8_t)((out << 2) | (out >> 6));
    }
    return out;
}

A moderate, non-degenerate signal — and we're saying exactly what that does and doesn't prove.

A 200,000-sample batch was collected from the prototype running in a containerized Linux environment, scored by both the implemented continuous health tests and a fast, non-authoritative sanity-check estimator for early-stage screening only.

Six concrete openings, beyond matching the incumbent's certificate.

What could slow this down — planned for, not treated as a surprise.