High-level point: Hashing multiple entropy sources is fine as an “entropy combiner” if you treat hashing as extraction (remove bias, collisions) and you have reliable, independent, min-entropy estimates. For a production RNG with long-lived state, prefer a standardized DRBG (e.g., HMAC-DRBG / CTR-DRBG / Hash-DRBG) because it provides proven extract-then-expand primitives, internal state management, reseeding logic, and forward/backward security guarantees.
Why simple hashing can be adequate
- Use-case: one-shot seed accumulation (e.g., boot seed) where you collect many independent sources and immediately seed a secure PRF-based generator.
- Requirements: each source has quantified min-entropy; adversary cannot control > allowed threshold; you apply a proper extractor (HMAC or HKDF-style keyed extract) rather than raw hash concatenation.
- Example: seed = HKDF-Extract(salt, concat(samples)) then key the PRF. HKDF provides proven entropy extraction even when some inputs are weak.
When to use a standardized DRBG
- Long-lived generator, repeated outputs, networked devices, or where state compromise is a real risk.
- DRBGs specify internal state update rules, reseed intervals, prediction resistance modes, and limits on output-per-seed (e.g., NIST SP800‑90A constraints).
- HMAC-DRBG gives a keyed PRF with internal K/V state and standardized reseed_counter semantics—this yields established forward secrecy on rekey and bounds on prediction after partial compromise.
Designing reseed policy and procedures
- Entropy thresholds: require reseed when accumulated fresh entropy ≥ security_strength bits (e.g., 128/256).
- Event triggers: periodic (time-based), request-count-based, health-test failure, or external event (network compromise).
- Parameters: follow standards—e.g., limit output-per-reseed and reseed intervals (NIST suggests a reseed_counter limit like 2^48 for DRBGs; choose conservative values for embedded or high-risk systems).
- Practical: reseed if either T seconds elapsed OR R outputs produced OR new hardware event; require at least X bits of estimated entropy from independent sources before accepting reseed.
State-compromise recovery
- Detection: monitor entropy source health tests, seed-usage anomalies, and external alerts.
- Immediate steps on suspected compromise:
- Stop using existing generator output.
- Gather fresh entropy from multiple independent sources; require conservative min-entropy (exceed security strength).
- Reinitialize using an extractor (HKDF/HMAC) with fresh randomness and a new unique salt/nonce.
- If possible, perform forward-recovery: rotate keys derived from the DRBG only after reseeding with entropy that adversary cannot have seen.
- Additional mitigations:
- Use forward-secure constructions (periodic rekey) so past outputs remain safe after compromise.
- Keep an immutable audit log of reseed events and entropy estimates.
- Zeroize internal state on compromise and enforce secure erasure.
Practical recommendations for a cryptographer
- Prefer extract-then-expand (HMAC/HKDF) over raw hash concatenation.
- Use a standardized DRBG for long-lived use and follow NIST/ISO guidance for limits and reseed policies; tune reseed counters conservatively for your threat model.
- Always perform health tests, conservative entropy estimation, and require entropy from diverse, independent sources for reseed.
- Define and document an incident response (stop, gather >security_strength bits, reinit, rotate dependent keys, log).
This approach balances theoretical soundness (provable extraction and PRF security) with operational resilience (reseed, detection, recovery).
