The rest of the entropy rationale covers the subtle statistical and failure-mode properties that separate a secure source from a plausible-looking one.
| Guidance | |
|---|---|
| Uniqueness ≠ numeric distinctness | Each ES16 read is freshly sampled physical entropy; over many reads, values WILL repeat by chance (16 bits → birthday collisions). “Unique randomness” means fresh sampling + wipe, not distinct numbers. |
| Fail closed (DEAD) | An unrecoverable source failure reports DEAD loudly rather than degrading to predictable output — so software refuses key generation instead of silently weakening keys. |
| No secret-dependent timing on poll | The poll interface itself must not leak (via timing) information about the entropy being delivered — consistent with the Zkt philosophy. |
| Conditioning bounds | The spec gives guidance on how much raw entropy to collect per output bit given the source’s min-entropy rate — the SP 800-90B accounting that makes “256 reads for 256 bits” a floor, not a guess. |
Hardware Designer Notes
For the hardware team, the takeaway is that the entropy source is the one crypto block where “looks random” is a security hole. Invest in the certification and the health-reporting honesty; the SBox gates are the easy part. The next page closes the chapter with the formal Sail definitions that pin every instruction’s exact behavior.
Minimal Linux-boot hart MUST
- Guarantee fail-closed behavior: any source failure surfaces as DEAD or a latched BIST alarm, never as silent weak output
- Keep the poll interface free of entropy-dependent timing
MAY simplify / trap-and-emulate
- Document your source’s min-entropy rate so software can size its conditioning correctly per SP 800-90B
Check yourself — entropy recommendations II
1.Why does the interface guarantee an ES16 read returns unique randomness even when the numeric value matches a prior read?
2.What role does the DEAD state play in a security architecture?