Ein CSPRNG ist ein kryptografisch sicherer Pseudozufallszahlengenerator. Er berechnet neue Werte nach einem festen Verfahren aus einem geheimen internen Zustand. „Pseudozufällig“ bedeutet dabei nicht minderwertig: Die Berechnung lässt sich wiederholen, ihre Ergebnisse sollen ohne Kenntnis des geheimen Zustands aber praktisch unvorhersagbar sein. Dafür braucht es genügend Entropie, also Ungewissheit über die Eingaben aus Sicht des Angreifers, und eine korrekte Einbindung in die Anwendung.
Stellen Sie sich ein Programm vor, das geheime Werte für eine Wallet erzeugt. Ein Angreifer erfährt einige frühere Ausgaben. Bei einem sicheren Generator darf ihm das nicht helfen, die übrigen Werte zu erraten. Das ist anspruchsvoller als eine ansprechende Zahlenverteilung in einem Diagramm. RFC 4086 unterscheidet deshalb kryptografisch starke Folgen von üblichen Simulationsgeneratoren. Auch gute statistische Testergebnisse genügen nicht, wenn sich der Seed erraten lässt, also der Ausgangswert der Erzeugung. [1]
In technischen Unterlagen steht auch DRBG: deterministischer Zufallsbitgenerator. „Deterministisch“ heißt, dass derselbe Zustand und dieselben Eingaben zum selben Ergebnis führen. Der Zustand muss deshalb geheim bleiben. NIST SP 800-90A Rev. 1 beschreibt konkrete Verfahren: Hash_DRBG, HMAC_DRBG und CTR_DRBG. Das sind technische Mechanismen, kein Gütesiegel für jedes Programm, das ihren Namen verwendet. Zur Prüfung gehören auch Einstellungen, Herkunft der Entropie und tatsächliche Umsetzung im Code. [2]
Ein offengelegter Zustand wirft zwei Fragen auf: Kann ein Angreifer frühere geheime Ergebnisse rekonstruieren? Kann er die nächsten vorhersagen? Der Schutz früherer Ausgaben heißt Backtracking resistance, der Schutz zukünftiger Prediction resistance. Für Letzteren verlangt NIST SP 800-90A die wirksame Zuführung frischer Entropie, die neue Ergebnisse vom verratenen Zustand trennt. Ein weiterer Rechenschritt allein stellt die Sicherheit nicht unbedingt wieder her. Auch folgt aus der einen Schutzwirkung nicht automatisch die andere. [2]
Eine Bibliothek ist ein fertiger Softwarebaustein, den eine Wallet nutzen kann. Doch auch ihr Aufruf kann scheitern. Bei OpenSSL 3.5 liefern RAND_bytes() und RAND_priv_bytes() bei Erfolg 1, bei anderen Fehlern 0 und bei einer nicht unterstützten aktuellen Methode -1 zurück. Fällt die Entropiequelle aus, kann die Erzeugung verweigert werden. Das Programm muss diesen Rückgabewert prüfen, bevor es den vorgesehenen Speicherbereich, den Puffer, verwendet. Sonst könnte es Daten nutzen, die nie sicher erzeugt wurden. [3]
Bei Tests ist Wiederholbarkeit hilfreich: Entwickler wollen Ergebnisse mit einer bekannten Erwartung vergleichen. Die libsodium-Funktion randombytes_buf_deterministic() erzeugt deshalb aus demselben Seed dieselbe Folge. Im laufenden Betrieb sind unbeabsichtigte Wiederholungen dagegen problematisch. Ein Snapshot einer virtuellen Maschine speichert den Zustand des Rechners einschließlich seines Arbeitsspeichers. Beim Wiederherstellen können sich daher auch Generatorzustand und Ausgabe wiederholen. Kopien einer Umgebung liefern also nicht zwangsläufig voneinander unabhängige Geheimnisse. [4]
Ein Generator kann gute Zufallsdaten liefern, die eine Anwendung anschließend falsch verarbeitet. Werden sie durch einfache Restbildung bei einer Division auf einen kleineren zulässigen Bereich abgebildet, können manche Ergebnisse häufiger auftreten als andere. Die libsodium-Funktion randombytes_uniform() vermeidet dies durch gleichverteilte Auswahl unterhalb einer angegebenen Obergrenze. Für Schlüssel gelten zusätzlich die Regeln ihres Algorithmus. Sicherheit endet daher nicht bei der Erzeugung zufälliger Bytes, sondern hängt auch von deren weiterer Verwendung ab. [4]
Ein Nonce ist ein Wert für eine einzelne Verwendung in einem kryptografischen Verfahren. Welche Regeln gelten, bestimmt das Protokoll. RFC 8439 verlangt, dass sich ein Nonce mit demselben Schlüssel nicht wiederholt; zufälliges Aussehen allein garantiert keine Eindeutigkeit. RFC 6979 beschreibt dagegen, wie der für eine digitale Signatur benötigte Wert k deterministisch aus dem geheimen Schlüssel und der zu signierenden Nachricht berechnet wird. Das sind unterschiedliche Entwürfe, kein Widerspruch. „Überall Zufall hinzufügen“ ersetzt deshalb kein korrektes Verfahren. [5] [6]
Die Aufschrift CSPRNG sagt noch nicht, ob eine Wallet das Gesamtsystem richtig nutzt. Eine technische Prüfung betrachtet die konkrete Bibliotheksversion, den Start des Generators, Fehlerbehandlung und Verhalten nach Wiederherstellung oder Kopieren des Zustands. Die Dokumentation von OpenSSL und libsodium belegt Eigenschaften ihrer Funktionen, nicht die Sicherheit jeder aufrufenden Anwendung. Für Nutzer zählt auch das Danach: Ein perfekt erzeugtes Geheimnis schützt die Mittel nicht mehr, wenn später eine Sicherung offengelegt wird, mit der sich der Zugriff wiederherstellen lässt. [3] [4]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Cryptographic Entropy, Random Number Generator, Deterministic RNG, Seed Generation. Auf diesen Eintrag verweisen außerdem Dice Roll Entropy, Cryptographic Entropy, Random Number Generator, Deterministic RNG.