Detailed Description

The seed a worker holds, and the draw over it.

One draw: give me len bytes, and that is what comes back. The generator keeps its own schedule - it redraws from the platform once its budget is spent, so no caller sets the pace and no entropy source is drained by whichever module asks most often.

What belongs here and what does not

An algorithm whose specification dictates how it expands its randomness keeps that expansion and does not call this: ECDSA derives its nonce with the RFC 6979 HMAC-SHA256 DRBG (ecdsa.c), and ML-KEM is the FIPS 203 derandomized form, so its caller passes (d, z) and m in as values. This is the draw for the cases no specification pins down - a Diffie-Hellman private, SSH packet padding, a GUID, a WebSocket mask, a nonce - which would otherwise be one copy of the same expansion per caller.

The expansion

ChaCha20 keystream (RFC 8439) under the seed, the counter incrementing per 64-byte block. A stream cipher is what a keystream-from-a-seed is, it is already in the tree, and it costs one ARX permutation per 64 bytes rather than one HMAC per 32.

After every draw the seed is replaced with 32 fresh keystream bytes, so the state that produced a value is gone before the value is returned and a later disclosure does not recover an earlier draw. Independently of that ratchet, the seed is redrawn from the platform once the draw budget PROTOCORE_RAND_RESEED_BYTES is spent.

The seed lives in the caller's borrow, one span per worker, so two workers never share a generator and the draw path takes no lock.

Author: Douglas Quigg (dstroy0)

Date: 2026

Definition in file rng.h.