Key points
- Use multiple independent suites because each battery looks for different statistical weaknesses.
- Preserve versions, parameters, sample sizes, and raw logs so another reviewer can understand the result.
- Combine statistical testing with design review, secure seeding, failure handling, and production monitoring.
What the Rantropy core has been tested with
Rantropy keeps results from several established test families. PractRand was run over a 256 GB continuous stream window. ENT reported an entropy profile of 8.000000 bits per byte for the evaluated sample. Dieharder produced an assessment excerpt with no FAIL result across most evaluations, and NIST STS was executed in batches covering 2,000 sequences.
TestU01 BigCrush was also run and its core subtest output was retained for review. These results describe the tested builds, input conditions, and samples. They should not be shortened into a claim that every future output is certified or that a statistical suite proves cryptographic security.
Why one battery is not enough
ENT is a compact profile and useful as an early check, but it is not a comprehensive certification. PractRand is effective at examining long streams and can expose issues as the sample grows. Dieharder and NIST STS provide collections of tests with their own parameter and interpretation rules. BigCrush applies a broad, demanding battery that can reveal defects missed by smaller checks.
A small number of unusual p-values can occur by chance when many tests are run. Review the suite guidance, repeated runs, clustering, and reproducibility before labelling an individual result a defect.
What statistical testing cannot prove
A stream can pass statistical tests while the system remains vulnerable because of a predictable seed, key exposure, state reuse, broken access control, or implementation mistakes. Conversely, deterministic output used for a reproducible simulation may be valid for that purpose even though it should never generate a security secret.
- Review the generator construction and entropy source.
- Test startup, restart, fork, scaling, and degraded-dependency behavior.
- Protect keys and internal state and define rotation and incident procedures.
- Pin build artifacts and preserve test logs with checksums.
Turn a test report into maintainable evidence
Record the source commit, build checksum, test tool version, command, parameters, platform, start and end time, and output checksum. Re-run the agreed suite when the core algorithm, compiler, entropy path, or deployment architecture changes. A customer or auditor then sees which software was tested rather than a detached screenshot.