Entropy Mixing

Imagine two records of the same event. Their filenames differ, but the second record adds no independent unknown. Packet arrival times and disk access times can likewise be related. NIST SP 800-90B warns that entropy estimates for dependent sources cannot simply be added. First establish what remains uncertain when the attacker also knows the other inputs. [1]

A hash is a calculated fingerprint of data. But if an attacker knows all the inputs, they can calculate the same result. Neither a long hash nor an added public constant makes those inputs secret. RFC 4086 distinguishes mixing available uncertainty from deterministically producing further values. Properly designed mixing helps use what the sources actually provide; it cannot replace missing entropy. [2]

XOR compares bits: equal bits give zero and different bits give one. Thus X XOR X = 0 — mixing a value with its copy removes all uncertainty here. If instead one input is uniformly random and independent of the other, the result stays uniform. RFC 4086 uses this to show why assumptions matter. It is not a recipe for building a homemade wallet generator. [2]

When assessing a particular design, ask where its inputs come from and what an attacker can do to them. HKDF, a method for deriving cryptographic keys, uses an auxiliary input called salt. It need not be secret, but RFC 5869 assumes independence from the starting key material and requires the application to prevent an attacker from choosing or altering it. Salt is a parameter name here. A list of sources or random-looking output alone cannot guarantee security when a source fails. [4]

NIST SP 800-90B works with a primary noise source. It permits other source outputs to be appended to its data if they go through a vetted processing method called conditioning. In this setting, it credits them with no additional entropy. More inputs therefore do not automatically raise the recognized amount. This is a rule for a particular evaluation, not a claim that other sources can never help. [1]

The difference appears in OpenSSL 3.5, a cryptographic library that programs can use for encryption and random numbers. Its RAND_add() function mixes in data from a buffer, a designated area of memory. The num parameter specifies the number of bytes to read; randomness estimates their entropy in bytes from zero to num. The memory area’s size does not establish that estimate. The default generator normally initializes and replenishes entropy automatically from system sources. [3]

Adding fresh entropy to a generator is called reseeding. This is different from adding arbitrary data. OpenSSL 3.5 documentation says that in FIPS mode, which follows rules for cryptographic modules, application-provided data is not accepted as a trusted entropy source. It is mixed in only as additional input and does not count as a full reseed. Calling RAND_add() alone therefore does not establish that renewal. [3]

HKDF in RFC 5869 divides the work into HKDF-Extract and HKDF-Expand. The first step concentrates available input entropy into a working key; the second derives the required length of data from it. This does not obtain a further independent secret. The info parameter can bind the result to its intended use, such as identifying what a derived key is for. That context neither replaces quality initial material nor proves new entropy. [4]