Beim Mischen von Entropie werden mehrere Eingaben zu einem gemeinsamen Zustand oder Ergebnis verarbeitet. Eingebrachte Daten, belegte Entropie und anschließende deterministische Expansion sind zu unterscheiden. Zwei Schnittstellennamen bedeuten nicht zwangsläufig zwei unabhängige Quellen.
NIST SP 800-90B weist darauf hin, dass die gemeinsame Entropie abhängiger Quellen schwer zu schätzen sein kann. Paketankunftszeiten und Plattenzugriffszeiten können zusammenhängen. Ohne dokumentiertes Modell lassen sich ihre getrennten Schätzwerte daher nicht einfach addieren. [NIST SP 800-90B — Additional noise sources]
RFC 4086 verwendet XOR als einfaches Mischbeispiel. Eine unabhängige, gleichverteilte Eingabe erhält die Gleichverteilung des Ergebnisses, doch eine Kopie derselben Eingabe ergibt X XOR X = 0. Dies illustriert Abhängigkeit und ist keine Bauanleitung für eine Wallet. [RFC 4086 — Mixing and randomness requirements]
Starkes Mischen kann vorhandene Unsicherheit konzentrieren; ein deterministischer Hash bekannter Eingaben bleibt jedoch vorhersagbar. RFC 4086 unterscheidet Mischen und Expansion. Ergebnislänge und das Hinzufügen einer bekannten Konstanten belegen keine entsprechende Menge neuer Entropie. [RFC 4086 — Mixing and randomness requirements]
NIST SP 800-90B erlaubt zusätzliche Rauscheingaben zusammen mit der Primärquelle über geprüftes Conditioning, rechnet ihnen dabei aber keine zusätzliche Entropie an. Dies ist eine Bewertungsregel, keine Behauptung, dass andere Quellen niemals helfen können. [NIST SP 800-90B — Additional noise sources]
In OpenSSL 3.5 mischt RAND_add() num Bytes ein; randomness schätzt die Entropie in Bytes zwischen null und num. Die Pufferlänge allein rechtfertigt diese Schätzung nicht. Der Standardgenerator initialisiert und erneuert sich normalerweise automatisch aus Systemquellen. [OpenSSL 3.5 — RAND_add and FIPS reseeding]
Laut OpenSSL 3.5 sind Anwendungsdaten im FIPS-Modus nur zusätzliche Eingaben, keine vertrauenswürdige Entropiequelle. Ihr Einmischen zählt nicht als vollständiger Reseed. Ein Aufruf von RAND_add() allein belegt eine solche Erneuerung daher nicht. [OpenSSL 3.5 — RAND_add and FIPS reseeding]
RFC 5869 unterscheidet HKDF-Extract und HKDF-Expand. Ersteres konzentriert Eingabeentropie, Letzteres leitet die benötigte Länge ab. Der Parameter info bindet das Ergebnis an den Anwendungskontext; er ersetzt weder gutes Ausgangsmaterial noch belegt er neue Entropie. [RFC 5869 — HKDF extraction, expansion and independence]
Eine Prüfung sollte Eingabeherkunft, Abhängigkeiten, Angreifermöglichkeiten und das konkrete Verfahren feststellen. RFC 5869 behandelt ausdrücklich Unabhängigkeit und Salt-Manipulation. Eine Quellenliste oder ein Test auf zufälliges Aussehen allein belegt keine Sicherheit beim Ausfall einer Quelle. [RFC 5869 — HKDF extraction, expansion and independence]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Cryptographic Entropy, CSPRNG, True Random Number Generator, Seed Generation. Auf diesen Eintrag verweisen außerdem Dice Roll Entropy, True Random Number Generator.