485 / 691MIX-H

Entropy Mixing

Combining entropy inputs

Entropy Mixing combines inputs for generating secret values. Its benefit depends on unpredictability, dependencies and the actual mechanism; source count and hash length alone do not determine security.

Entropy mixing processes multiple inputs into a shared state or output. Supplied data, evidenced entropy and subsequent deterministic expansion must be distinguished. Two interface names need not represent two independent sources.

NIST SP 800-90B notes that joint entropy of dependent sources can be hard to estimate. Packet arrival and disk access times may be related. Their separate estimates therefore cannot simply be added without a documented model. [NIST SP 800-90B — Additional noise sources]

RFC 4086 uses XOR as a simple mixing example. An independent uniform input preserves uniformity of the result, but a copy of the same input gives X XOR X = 0. This illustrates dependence, not a wallet construction recipe. [RFC 4086 — Mixing and randomness requirements]

Strong mixing can concentrate available uncertainty; a deterministic hash of known inputs remains predictable. RFC 4086 distinguishes mixing and expansion. Output length and adding a known constant do not establish an equivalent amount of new entropy. [RFC 4086 — Mixing and randomness requirements]

NIST SP 800-90B allows additional noise inputs to be concatenated with a primary source through vetted conditioning, but credits them with no additional entropy in this setting. This is an evaluation rule, not a claim that other sources can never help. [NIST SP 800-90B — Additional noise sources]

In OpenSSL 3.5, RAND_add() mixes num bytes; randomness estimates entropy in bytes between zero and num. Buffer length alone does not justify that estimate. The default generator normally seeds and reseeds automatically from system sources. [OpenSSL 3.5 — RAND_add and FIPS reseeding]

OpenSSL 3.5 documentation states that in FIPS mode application data is only additional input, not a trusted entropy source. Mixing it does not count as a full reseed. Calling RAND_add() alone therefore does not establish such renewal. [OpenSSL 3.5 — RAND_add and FIPS reseeding]

RFC 5869 distinguishes HKDF-Extract and HKDF-Expand. The first concentrates input entropy; the second derives the required length. The info parameter binds output to application context; it neither replaces quality initial material nor proves new entropy. [RFC 5869 — HKDF extraction, expansion and independence]

A review should identify input origins, dependencies, attacker capabilities and the actual mechanism. RFC 5869 explicitly addresses independence and salt manipulation. A source list or a random-appearance test alone does not prove that the construction remains secure after source failure. [RFC 5869 — HKDF extraction, expansion and independence]

For the clearest picture, read this entry together with Cryptographic Entropy, CSPRNG, True Random Number Generator, Seed Generation. The reverse links also lead from Dice Roll Entropy, True Random Number Generator.

DOC · 001NIST SP 800-90B — Additional noise sourcesSpecification ↗DOC · 002RFC 4086 — Mixing and randomness requirementsSpecification ↗DOC · 003OpenSSL 3.5 — RAND_add and FIPS reseedingDocumentation ↗DOC · 004RFC 5869 — HKDF extraction, expansion and independenceSpecification ↗
Source-first · No investment advice