Entropy Mixing

Stellen Sie sich zwei Aufzeichnungen desselben Ereignisses vor. Sie haben unterschiedliche Dateinamen, doch die zweite liefert keine unabhängige Unbekannte. Ebenso können die Ankunftszeiten von Netzwerkpaketen und die Zeiten von Festplattenzugriffen zusammenhängen. NIST SP 800-90B warnt davor, Entropieschätzungen abhängiger Quellen einfach zu addieren. Zuerst muss geklärt werden, was ungewiss bleibt, wenn der Angreifer auch die anderen Eingaben kennt. [1]

Ein Hash ist ein berechneter Fingerabdruck von Daten. Kennt ein Angreifer aber alle Eingaben, berechnet er dasselbe Ergebnis. Weder ein langer Hash noch eine öffentliche Konstante macht daraus ein Geheimnis. RFC 4086 unterscheidet das Mischen vorhandener Ungewissheit vom deterministischen Erzeugen weiterer Werte. Richtig entworfenes Mischen nutzt, was die Quellen tatsächlich liefern; fehlende Entropie ersetzt es nicht. [2]

XOR vergleicht Bits: Gleiche ergeben null, unterschiedliche eins. Deshalb gilt X XOR X = 0 — eine Verknüpfung mit der eigenen Kopie entfernt hier jede Ungewissheit. Ist dagegen eine Eingabe gleichverteilt zufällig und unabhängig von der anderen, bleibt das Ergebnis gleichverteilt. RFC 4086 zeigt damit, warum die Voraussetzungen wichtig sind. Das ist keine Bauanleitung für einen eigenen Wallet-Generator. [2]

Fragen Sie bei einem konkreten Verfahren, woher die Eingaben stammen und was ein Angreifer damit tun kann. HKDF, ein Verfahren zum Ableiten kryptografischer Schlüssel, nutzt etwa eine zusätzliche Eingabe namens salt. Sie muss nicht geheim sein. RFC 5869 setzt aber ihre Unabhängigkeit vom Ausgangsmaterial für den Schlüssel voraus; die Anwendung muss verhindern, dass ein Angreifer sie auswählt oder verändert. Salt ist hier ein Parametername. Eine Quellenliste oder zufällig wirkende Ausgabe allein garantiert keine Sicherheit beim Ausfall einer Quelle. [4]

NIST SP 800-90B geht von einer primären Rauschquelle aus. Ausgaben weiterer Quellen dürfen an deren Daten angehängt werden, wenn sie gemeinsam ein geprüftes Aufbereitungsverfahren namens Conditioning durchlaufen. In diesem Rahmen wird ihnen jedoch keine zusätzliche Entropie angerechnet. Mehr Eingaben erhöhen den anerkannten Wert somit nicht automatisch. Das ist eine Regel der konkreten Bewertung, keine Aussage, dass weitere Quellen niemals helfen können. [1]

Den Unterschied zeigt OpenSSL 3.5, eine Kryptografiebibliothek für Programme, die etwa Verschlüsselung und Zufallszahlen benötigen. Ihre Funktion RAND_add() mischt Daten aus einem Puffer ein, also einem vorgesehenen Speicherbereich. num gibt an, wie viele Bytes gelesen werden; randomness schätzt deren Entropie in Bytes zwischen null und num. Die Größe des Speicherbereichs belegt diese Schätzung nicht. Der Standardgenerator initialisiert sich normalerweise selbst und ergänzt automatisch Entropie aus Systemquellen. [3]

Das Ergänzen frischer Entropie im Generator heißt Reseeding. Es ist etwas anderes als das Hinzufügen beliebiger Daten. Laut OpenSSL 3.5 gelten Anwendungsdaten im FIPS-Modus, der Regeln für kryptografische Module folgt, nicht als vertrauenswürdige Entropiequelle. Sie werden nur als zusätzliche Eingabe eingemischt und zählen nicht als vollständiger Reseed. Der Aufruf von RAND_add() allein belegt daher keine solche Erneuerung. [3]

HKDF nach RFC 5869 teilt die Arbeit in HKDF-Extract und HKDF-Expand. Der erste Schritt bündelt vorhandene Eingabeentropie in einem Arbeitsschlüssel; der zweite leitet daraus Daten der gewünschten Länge ab. Ein weiteres unabhängiges Geheimnis entsteht dabei nicht. Mit info lässt sich die Ausgabe an ihren Verwendungszweck binden, etwa daran, wofür ein abgeleiteter Schlüssel gedacht ist. Dieser Kontext ersetzt weder gutes Ausgangsmaterial noch belegt er neue Entropie. [4]