Jede verschlüsselte Nachricht, jede sichere Banksitzung, jede digitale Signatur, die ein Software-Update schützt, beruht auf derselben unsichtbaren Grundlage: unvorhersehbaren Zufallszahlen. Kryptografische Schlüsselerzeugung ist der Prozess, der Chaos in Sicherheit verwandelt und rohe Zufälligkeit in Schlüssel umwandelt, die unsere digitale Infrastruktur schützen. Versagt diese Zufälligkeit, versagt alles, was darauf aufgebaut ist.
Die Mathematik hinter der Verschlüsselung ist elegant und gut erforscht. Weniger verstanden ist die ebenso entscheidende Rolle der Entropie, der Unvorhersehbarkeit, die Schlüssel unmöglich zu erraten macht. Eine internetweite Studie aus dem Jahr 2012 ergab, dass Forscher RSA-Privatschlüssel für 0,50 % der TLS-Hosts und 0,03 % der SSH-Hosts erlangen konnten, weil öffentliche Schlüssel nichttriviale gemeinsame Faktoren teilten, ein Fehler, den die Autoren hauptsächlich auf unzureichende Entropie in headless- und eingebetteten Geräten zurückführten[s]. In diesem Scan repräsentierte der TLS-Anteil allein etwa 64.000 Hosts.
Die zwei Säulen kryptografischer Sicherheit
Kryptografie steht auf zwei Grundlagen. Die erste ist mathematische Komplexität: Algorithmen basieren auf Problemen, die leicht aufzustellen, aber außerordentlich schwer umzukehren sind. Die zweite ist Zufälligkeit. Kryptografische Protokolle verwenden Zufallszahlen, um geheime Schlüssel, Initialisierungsvektoren und Nonces zu erzeugen. Diese Werte müssen unvorhersehbar sein. Kann ein Angreifer sie erraten oder reproduzieren, wird die mathematische Komplexität irrelevant[s].
Stellen Sie es sich so vor: Man kann das stärkste Schloss der Welt einbauen, aber wenn jemand den Schlüssel vorhersagen kann, nützt das Schloss nichts. Die Verschlüsselungsmathematik, die Ihre Kommunikation schützt, kann nicht durch mathematische Schwäche, sondern durch vorhersehbare Zufälligkeit gebrochen werden.
Wie Computer Zufälligkeit erzeugen
Computer sind deterministische Maschinen. Bei gleichen Eingaben erzeugen sie gleiche Ausgaben. Das ist das Gegenteil von Zufälligkeit. Um unvorhersehbare Zahlen zu generieren, sammeln Betriebssysteme Entropie aus physikalischen Quellen: Zeitvariationen bei Tastenanschlägen, Festplattenoperationen, dem Eintreffen von Netzwerkpaketen und elektronischem Rauschen in Hardwarekomponenten.
Moderne Linux-Systeme unterhalten einen einzigen Entropie-Pool, der von einem ChaCha20-basierten kryptografisch sicheren Pseudozufallszahlengenerator (CSPRNG) gespeist wird. Hardware-Ereignisunterbrechungen tragen Timing-Jitter bei, der den Eingang des Pools speist[s]. Sobald dieser Pool mindestens 256 Bits geschätzter Entropie angesammelt hat, kann das System unbegrenzt kryptografisch starken Output erzeugen.
Ein CSPRNG muss zwei kritische Eigenschaften erfüllen. Erstens den Nächstes-Bit-Test: Bei jeder Ausgabebitfolge kann kein effizienter Algorithmus das nächste Bit mit einer Wahrscheinlichkeit von deutlich mehr als 50 % vorhersagen[s]. Zweitens Rückwärtsgeheimhaltung: Selbst wenn ein Angreifer den aktuellen Zustand des Generators kompromittiert, kann er nicht bestimmen, welche Zahlen zuvor generiert wurden[s].
Wenn Zufälligkeit versagt: reale Katastrophen
Die Geschichte liefert ernüchternde Beispiele dafür, was geschieht, wenn kryptografische Schlüsselerzeugung auf schwacher Zufälligkeit beruht.
Die 2008 bekannt gewordene Debian-OpenSSL-Schwachstelle entstammte einer Debian-spezifischen Änderung, die erstmals im September 2006 hochgeladen wurde. Der Fehler ließ die Prozess-ID als effektiv einzige Zufälligkeitsquelle für OpenSSL auf betroffenen Debian-Systemen zurück[s][s]. Anstelle des vorgesehenen Suchraums mit 340.282.366.920.938.463.463.374.607.431.768.211.456 Werten konnten Angreifer 32.767 PID-abgeleitete Möglichkeiten für viele betroffene Schlüssel aufzählen.
Ende 2010 deckte fail0verflow einen PlayStation-3-Signierfehler auf: Sonys Signiersoftware verwendete eine konstante Zahl, wo die Signaturberechnung einen wirklich zufälligen, unvorhersehbaren Wert erforderte. Dieser Fehler ermöglichte Hackern die Berechnung von Sonys privatem Signierschlüssel[s].
2012 führten Forscher eine einfache mathematische Operation (Berechnung des größten gemeinsamen Teilers) über 11 Millionen verschiedene RSA-Öffentlichkeitsmoduln durch und erhielten Privatschlüssel für 0,50 % der TLS-Hosts und 0,03 % der SSH-Hosts in ihrem Scan. Sie reproduzierten ein Boot-Zeit-Entropieloch im Linux-Zufallszahlengenerator unter Bedingungen, die wahrscheinlich in headless- und eingebetteten Geräten auftreten[s].
Dies sind keine Einzelfälle. Schwache Zufälligkeit hat über Jahrzehnte der Computertechnik wiederholt zu Sicherheitslücken geführt. 2024 führte ein subtiler Fehler in PuTTY (Versionen 0.68 bis 0.80) zu statistischer Verzerrung bei der ECDSA-Nonce-Generierung, was Angreifern ermöglichte, private Signierschlüssel aus etwa 60 Signaturen wiederherzustellen[s].
Die 256-Bit-Schwelle
Warum 256 Bits? Es ist keine universelle Anforderung für jeden kryptografischen Schlüssel, aber es ist ein verbreitetes hochklassiges Sicherheitsstärkenziel und der Initialisierungsschwellenwert des Linux-RNG. Ein 256-Bit-Schlüssel hat rund 1,16 × 1077 mögliche Werte—einen astronomisch großen Schlüsselraum. Selbst wenn ein Angreifer eine Billion Schlüssel pro Sekunde prüfen könnte, würde die Erschöpfung dieses Raums länger dauern als das Alter des Universums.
NIST Special Publication 800-133 Rev. 2 ist die aktuelle abschließende NIST-Empfehlung zur kryptografischen Schlüsselerzeugung, während Rev. 3 im April 2026 als erster öffentlicher Entwurf veröffentlicht wurde. NIST beschreibt Kryptografie als abhängig von einem Algorithmus und einem kryptografischen Schlüssel; die Empfehlung umfasst die Erzeugung von Schlüsseln, die von zugelassenen kryptografischen Algorithmen verwaltet und verwendet werden[s][s]. Die praktische Anforderung ist eine angemessene Sicherheitsstärke für den Algorithmus, nicht dass jeder kryptografische Schlüssel genau 256 Bits Entropie enthält.
Jenseits des klassischen Computing: Post-Quanten-Bedenken
Quantencomputer bedrohen die mathematischen Grundlagen der aktuellen Kryptografie. Shors Algorithmus kann große Zahlen exponentiell schneller faktorisieren als klassische Methoden und gefährdet damit möglicherweise RSA. Er löst auch das diskrete Logarithmusproblem, das der Kryptografie über elliptische Kurven zugrunde liegt[s].
Post-Quanten-kryptografische Schlüsselerzeugung verwendet andere mathematische Probleme. Das Module-Learning-With-Errors-Problem (MLWE) liegt dem ML-KEM-Algorithmus zugrunde, den NIST 2024 standardisiert hat[s]. Vereinfacht ausgedrückt geht es bei LWE-Familienproblemen darum, einen geheimen Vektor zu finden, wenn nur verrauschte lineare Informationen darüber vorliegen[s]. NIST erklärt, ML-KEM gelte als sicher selbst gegen Gegner mit einem Quantencomputer.
Doch selbst Post-Quanten-Algorithmen sind nicht immun gegen schwache Zufälligkeit. FIPS 203 besagt, dass die Sicherheitsgarantien von ML-KEM davon abhängen, dass mehrere Werte geheim bleiben, einschließlich der von beiden Parteien verwendeten Zufälligkeit[s]. Die mathematische Schwierigkeit des Algorithmus wird irrelevant, wenn die ihn speisende Zufälligkeit erraten werden kann.
Architektur des Entropie-Pools
Moderne kryptografische Schlüsselerzeugung beginnt mit der Entropiesammlung. Der Linux-Kernel unterhält einen einzigen Entropie-Pool, der von einem ChaCha20-basierten CSPRNG gespeist wird. Hardware-Ereignisunterbrechungen, darunter Tastenanschläge, Festplattenabschlüsse, Timing von Netzwerkpaketeingängen und USB-Ereignisse, tragen Timing-Jitter bei, der den Eingang des Pools speist[s]. Der Pool verwendet BLAKE2s (seit Kernel 5.17) für das Eingangs-Hashing und faltet neue Entropie in den bestehenden Zustand ein.
Die entscheidende Unterscheidung: Entropieschätzung (eingemischte Bits unvorhersehbarer Eingabe) ist von der Ausgabegenerierung (produzierte pseudozufällige Bytes) getrennt. Sobald der Pool den 256-Bit-Initialisierungsschwellenwert erreicht, erzeugt der ChaCha20-CSPRNG unbegrenzt Output mit kryptografischen Sicherheitsgarantien.
Vor Kernel 5.6 blockierte /dev/random, wenn Entropieschätzungen unter den Schwellenwert fielen, während /dev/urandom Output ohne dieselbe Blocksemantik zurückgab. Seit Kernel 5.6 blockiert /dev/random nach dem frühen Systemstart nicht mehr, aber aktuelle Linux-Handbuchseiten warnen noch, dass /dev/urandom beim frühen Start Daten vor der Initialisierung zurückgeben kann. Der getrandom(2)-Syscall, eingeführt in Kernel 3.17, ist die bevorzugte Schnittstelle für startempfindliche Anwendungen, da er bis zur Initialisierung des Entropie-Pools blockiert, sofern nicht GRND_NONBLOCK gesetzt ist[s][s].
CSPRNG-Sicherheitseigenschaften
Ein kryptografisch sicherer Pseudozufallszahlengenerator muss formale Sicherheitsanforderungen erfüllen. Der Nächstes-Bit-Test erfordert, dass bei jeder Ausgabefolge kein polynomialzeitlicher Algorithmus das nächste Bit mit einer Wahrscheinlichkeit von deutlich mehr als 50 % vorhersagen kann[s]. Der Schutz vor Zustandskompromittierungsausweitung stellt sicher, dass ein Angreifer, der den internen Zustand kompromittiert, keine vor der Kompromittierung generierten Zahlen bestimmen kann[s].
Der CSPRNG verwendet eine sichere Einwegkryptografiefunktion (eine Hashfunktion wie SHA-256 oder eine Blockchiffre wie AES), um internen Zustand zu mischen und Output zu erzeugen. Der Output wird dann in den internen Zustand zurückgespeist[s]. NIST SP 800-90A Rev. 1 spezifiziert genehmigte DRBG-Mechanismen (Deterministic Random Bit Generator) auf Basis von Hashfunktionen und Blockchiffren[s].
Fehlermodi bei der kryptografischen Schlüsselerzeugung
Die Debian-OpenSSL-Schwachstelle, 2008 offengelegt und durch eine Debian-spezifische Änderung eingeführt, die erstmals am 17. September 2006 hochgeladen wurde, demonstriert katastrophales Entropieversagen[s]. Der Fehler ließ nur die Prozess-ID (PID) als effektiven Zufälligkeitseintrag übrig[s]. Da Linux-PIDs üblicherweise von 0 bis 32.767 reichen, kollabierte eine Vielzahl betroffener Schlüssel zu einer aufzählbaren Menge, die vorberechnet werden konnte.
Die Forschungsarbeit „Mining Your Ps and Qs“ von 2012 nutzte einen subtileren Fehler aus. Die RSA-Schlüsselerzeugung erfordert die Auswahl zweier großer Zufallsprimzahlen p und q; der öffentliche Modulus ist N = p × q. Wenn zwei Schlüssel einen Primfaktor teilen (d. h. N₁ = p × q₁ und N₂ = p × q₂), enthüllt die Berechnung von ggT(N₁, N₂) den Wert p und faktorisiert so beide Schlüssel sofort. Die Forscher berechneten ggTs über 11 Millionen verschiedene RSA-Moduli und erhielten Privatschlüssel für 0,50 % der TLS-Hosts und 0,03 % der SSH-Hosts in ihrem Scan; schwache Schlüssel konzentrierten sich auf headless- und eingebettete Geräte, die Schlüssel mit unzureichender Entropie erzeugten[s].
Die PuTTY-Schwachstelle von 2024 (CVE-2024-31497) betraf ECDSA-Nonce-Verzerrung. ECDSA erfordert einen einzigartigen, unvorhersehbaren Nonce k für jede Signatur. PuTTYs P-521-Signaturgenerator erzeugte Nonce-Werte, deren oberste neun Bits stets null waren, was statistische Verzerrung einführte. Aus etwa 60 Signaturen konnte ein Angreifer den privaten Signierschlüssel wiederherstellen[s].
Hardware-RNG und Vertrauensgrenzen
Intels RDRAND-Anweisung (Ivy Bridge, 2012) und AMDs Implementierung (Zen, 2017) bieten hardwarebasierte Zufallszahlenerzeugung. Die ausschließliche Abhängigkeit von Hardware-RNG schafft jedoch Vertrauensbedenken. 2019 gaben AMD-Ryzen-Systeme mit bestimmten Firmware-Versionen konstante Werte aus RDRAND zurück, ein bestätigter Fehler, der jedes System, das ihm ausschließlich vertraut, katastrophal geschwächt hätte[s].
Das aktuelle Kernel-Verhalten verknüpft den RDRAND-Output per XOR als einen von mehreren Eingaben in den Entropie-Pool. Diese Defense-in-Depth-Strategie stellt sicher, dass kompromittierte Hardware den Pool allein nicht kompromittieren kann, solange andere Entropieeingaben unabhängig bleiben.
Post-Quanten-Schlüsselerzeugung
Shors Algorithmus reduziert ganzzahlige Faktorisierungs- und diskrete Logarithmusprobleme auf Periodensuche, die auf einem Quantencomputer in polynomialer Zeit lösbar ist[s]. Dies bedroht RSA, Diffie-Hellman und die Kryptografie über elliptische Kurven.
Post-Quanten-kryptografische Schlüsselerzeugung stützt sich auf gitterbasierte Probleme. Das Module-Learning-With-Errors-Problem (MLWE), das ML-KEM zugrunde liegt, beinhaltet das Finden eines geheimen Vektors s bei gegebenem (A, b), wobei b = A·s + e mod q gilt, A eine Zufallsmatrix und e ein kleiner Fehlervektor ist[s]. Die Rauschaddition macht dieses Problem selbst für Quantencomputer schwer, da es auf das Closest-Vector-Problem auf Gittern abgebildet wird.
Doch Entropieanforderungen lockern sich für Post-Quanten-Systeme nicht. FIPS 203 besagt, dass die ML-KEM-Sicherheit davon abhängt, mehrere Werte geheim zu halten, darunter die von beiden Parteien verwendete Zufälligkeit[s]. Mathematische Schwierigkeit kann vorhersehbare Eingaben nicht kompensieren.
Schlüsselableitung und Wallet-Standards
Kryptowährungs-Wallets implementieren hierarchische Schlüsselableitung gemäß den BIP-32-, BIP-39- und BIP-44-Standards. Diese Protokolle übertragen Entropie in Zufallszahlen, dann in mnemonische Phrasen und schließlich in hierarchische Schlüssel, die Vermögenswerte kontrollieren[s]. Einige Hardware-Wallets isolieren die Schlüsselerzeugung in dedizierter Hardware mit echten Zufallszahlengeneratoren und trennen so die Entropiesammlung von potenziell kompromittierten Allzweck-Betriebssystemen.
