DRBG (seed-and-stretch)

A DRBG (Deterministic Random Bit Generator) expands a small high-quality seed into a large stream of cryptographically strong randomness. The seed-and-stretch pattern pairs an expensive, high-assurance entropy source (such as a QRNG service) with a fast local DRBG, reseeding on a schedule, so systems get physical-grade entropy without paying network latency per random byte.

The pattern exists because of a latency mismatch. A physical entropy source may be a network call away, while randomness is needed per request, so the DRBG absorbs the difference: seed rarely, expand locally, reseed on a schedule or after a volume threshold.

The security of the arrangement rests on the seed and on the reseed interval, which is why both belong in the record of what a given output was derived from.

The security of the arrangement rests on two things a reviewer can check: the quality and secrecy of the seed, and how often reseeding happens. Neither is visible from the output, which is why both belong in a record rather than in a comment, and why a system that cannot say which seed a given output descended from cannot support a claim about that output.

Reseeding policy is a trade between assurance and availability. Reseeding often narrows the window in which a compromised state matters and increases dependence on the seed source being reachable; reseeding rarely does the opposite. Deciding it on a volume threshold as well as a time interval covers the case where a process generates far more output than expected.

State compromise is the failure mode worth naming, because a deterministic generator whose internal state leaks produces predictable output until the next reseed. That is the argument for backtracking resistance in the construction and for keeping the state in memory that is not written to disk, and it is unaffected by how good the QRNG that seeded it was.

Recording the seed reference alongside the output is what makes the derivation auditable, in the same way crypto-agility depends on recording which algorithm produced an artifact.

PasskeyBridge verifies identity signals like these inside the request, with zero PII stored. See how the platform works or test the live API.