Zum Hauptinhalt springen

Entropie und Zufälligkeit in Kryptowährungen: Warum sie wichtig sind

Jeder private Schlüssel einer Kryptowährung, jede Seed Phrase und jede Adresse, die du verwendest, beginnt mit einer Zufallszahl. Die Sicherheit deines gesamten Krypto-Portfolios basiert auf einer Annahme: Diese Zahl war wirklich unvorhersehbar. Wenn der Zufallszahlengenerator, der deinen Schlüssel erzeugt hat, schwach, verzerrt oder vorhersagbar war, können deine Gelder gestohlen werden, nicht durch das Brechen von Kryptografie, sondern durch das Erraten des Schlüssels.

Dieser Leitfaden erklärt, was Entropie im kryptografischen Kontext bedeutet, wie Zufallszahlengeneratoren funktionieren, was historisch schiefgelaufen ist, wenn Zufälligkeit versagt hat, und wie du sicherstellst, dass deine Schlüsselerzeugung zuverlässig ist.

Was ist Entropie?​

In der Informationstheorie misst Entropie das Maß an Unsicherheit oder Unvorhersehbarkeit in einem Datensatz. In der Kryptografie quantifiziert Entropie, wie viele Bits echter Zufälligkeit ein Wert enthält.

Ein 256-Bit-Privatschlüssel sollte 256 Bit Entropie haben. Das bedeutet, dass ein Angreifer im Durchschnitt 2^255 Versuche benötigt, um ihn zu finden (im Mittel die Hälfte des Suchraums). Wenn der Schlüssel nur mit 32 Bit tatsächlicher Entropie erzeugt wurde (weil der RNG fehlerhaft war), benötigt der Angreifer nur etwa 2^31 Versuche, also rund 2 Milliarden, was ein moderner Computer in Minuten durchprobieren kann.

Entropie messen​

Entropie wird in Bits gemessen. Die Entropie einer Zufallsvariablen X ist:

H(X) = -sum(p(x) * log2(p(x))) for all possible values x

Für eine gleichverteilte 256-Bit-Zahl:

  • Jedes Bit hat die Wahrscheinlichkeit 0,5, 0 oder 1 zu sein.
  • Entropie = 256 Bit (Maximum für diese Größe).

Für einen verzerrten Generator, bei dem jedes Bit mit Wahrscheinlichkeit 0,7 eine 1 ist:

  • Entropie pro Bit = -(0.7 * log2(0.7) + 0.3 * log2(0.3)) = 0.881 bits.
  • Gesamtentropie für 256 Bit = 225.5 bits (11.9% weniger als ideal).

Selbst kleine Verzerrungen summieren sich über viele Bits und können das effektive Sicherheitsniveau deutlich reduzieren.

Entropie im BIP-39-Kontext​

Länge der MnemonicEntropieSicherheitsniveauBrute-Force bei 10^12/s
12 Wörter128 Bit128-Bit~10^19 Jahre
15 Wörter160 Bit160-Bit~10^28 Jahre
18 Wörter192 Bit192-Bit~10^38 Jahre
24 Wörter256 Bit256-Bit~10^57 Jahre

Diese Zahlen setzen voraus, dass die Entropie wirklich gleichverteilt ist. Wenn der RNG fehlerhaft ist, kann das tatsächliche Sicherheitsniveau drastisch niedriger sein.

Arten von Zufallszahlengeneratoren​

True Random Number Generators (TRNG)​

TRNGs sampeln physikalische Phänomene, die auf Quantenebene inhärent unvorhersehbar sind:

  • Thermisches Rauschen — Zufällige Spannungsschwankungen in Widerständen, verursacht durch thermische Bewegung von Elektronen.
  • Schrotrauschen — Zufällige Stromschwankungen aufgrund der diskreten Natur des Elektronenflusses.
  • Radioaktiver Zerfall — Das Timing einzelner Zerfallsereignisse ist grundsätzlich unvorhersehbar.
  • Atmosphärisches Rauschen — Hochfrequenzrauschen durch Blitze und andere atmosphärische Prozesse.

Hardware-Wallets wie Ledger und Trezor verwenden On-Chip-TRNGs. Diese sampeln physikalische Rauschquellen und konditionieren die Ausgabe durch Whitening und Gesundheitstests.

Vorteile: Echte Zufälligkeit aus physikalischen Prozessen; kein deterministischer Zustand, der vorhergesagt werden kann.
Nachteile: Hardware-abhängig; kann bei degradierter Rauschquelle still ausfallen; Durchsatz kann begrenzt sein.

Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)​

Ein CSPRNG ist ein deterministischer Algorithmus, der eine Ausgabe erzeugt, die bei ausreichend zufälligem Seed nicht von echter Zufälligkeit zu unterscheiden ist:

  • Linux: /dev/urandom (verwendet ChaCha20 oder eine ähnliche Chiffre, gesät aus Hardware-Entropie).
  • macOS: /dev/urandom (arc4random, gesät aus Hardware-Entropie).
  • Windows: BCryptGenRandom (CNG-Provider).
  • Webbrowser: crypto.getRandomValues() (delegiert an den OS-CSPRNG).
  • Python: os.urandom() oder secrets-Modul.
  • Node.js: crypto.randomBytes().

Vorteile: Schnell; gut untersuchte Algorithmen; auf allen Plattformen verfügbar.
Nachteile: Nur so stark wie die initiale Seed-Entropie; deterministisch, wenn der interne Zustand bekannt ist, ist jede zukünftige Ausgabe vorhersagbar.

Nicht-kryptografische PRNGs (NIEMALS für Schlüssel verwenden)​

Standard-Zufallsfunktionen in den meisten Programmiersprachen sind für statistische Simulation gedacht, nicht für Kryptografie:

  • Python: random.random() (Mersenne Twister — deterministisch, Zustand aus 624 Ausgaben rekonstruierbar).
  • JavaScript: Math.random() (xorshift128+ in V8 — vorhersagbar).
  • C: rand() (linearer kongruenter Generator — trivial vorhersagbar).
  • Java: java.util.Random (linear kongruent — vorhersagbar).

Diese Generatoren haben geringe Entropie, kurze Perioden und vorhersagbaren Zustand. Sie für die Schlüsselerzeugung zu verwenden, ist gleichbedeutend damit, überhaupt keine Zufälligkeit zu verwenden. Erzeuge niemals private Schlüssel oder Seed Phrases mit diesen Funktionen.

Historische Ausfälle von Zufälligkeit​

Der Android-SecureRandom-Bug (2013)​

Im August 2013 wurde ein kritischer Fehler in Androids Implementierung von SecureRandom entdeckt. Der Java-PRNG wurde auf bestimmten Android-Geräten nicht korrekt gesät, wodurch mehrere Bitcoin-Wallet-Apps private Schlüssel aus einem vorhersagbaren Zustand erzeugten. Ein Angreifer nutzte dies aus und stahl ungefähr 55 BTC. Der Bug betraf die Erzeugung des ECDSA-Signatur-Nonce. Wenn derselbe Nonce zweimal verwendet wird, kann der private Schlüssel aus zwei Signaturen berechnet werden.

Der "Blockchain Bandit" (2019)​

Der Sicherheitsforscher Adrian Bednarek entdeckte, dass Wallets mit trivial schwachen privaten Schlüsseln erzeugt worden waren, z. B. Schlüssel wie 1, 2, 3 oder einmal gehashte einfache Wörterbuchwörter. Ein Angreifer hatte über Jahre systematisch Gelder von diesen Adressen abgeschöpft und mehr als 45.000 ETH angesammelt. Der Bandit enumerierte einfach Schlüssel mit niedriger Entropie und prüfte, ob darauf Gelder lagen.

Beispiele für geleerte Schlüssel:

  • Privater Schlüssel 0x0000000000000000000000000000000000000000000000000000000000000001 (die Zahl 1)
  • Private Schlüssel, abgeleitet aus häufigen Passwörtern und Phrasen

Die Milk-Sad-Schwachstelle (2023)​

Der seed-Befehl des Tools libbitcoin-explorer (bx) nutzte Mersenne Twister, gesät nur mit 32 Bit Systemzeit. Das bedeutete, dass alle mit diesem Tool erzeugten Schlüssel höchstens 32 Bit Entropie hatten, also ungefähr 4,3 Milliarden Möglichkeiten. Angreifer brute-forcten diese Schlüssel und stahlen Gelder.

Debian OpenSSL Weak Key Bug (2008)​

Ein Debian-Maintainer entfernte versehentlich eine Codezeile, die OpenSSLs Zufallszahlengenerator mit Entropie versorgte. Über zwei Jahre (2006-2008) hatte jeder auf Debian- und Ubuntu-Systemen erzeugte kryptografische Schlüssel nur 15 Bit Entropie aus der Prozess-ID und erzeugte höchstens 32.767 eindeutige Schlüssel. Alle SSH-Schlüssel, SSL-Zertifikate und alle Kryptowährungsschlüssel, die in diesem Zeitraum auf betroffenen Systemen erzeugt wurden, waren kompromittiert.

Erkenntnisse​

  1. Vertraue niemals ohne Verifikation nur einer einzigen Entropiequelle.
  2. Kleine Implementierungsfehler können Entropie katastrophal reduzieren.
  3. Angreifer nutzen schwache Zufälligkeit aktiv aus, das ist nicht nur Theorie.
  4. Open-Source-Code mit Audits ist für entropiekritische Operationen essenziell.

Entropiequellen im Detail​

Entropiepool des Betriebssystems​

Moderne Betriebssysteme verwalten einen Entropiepool, der aus mehreren Quellen gespeist wird:

  • Interrupt-Timing — Das Timing von Hardware-Interrupts (Tastatur, Maus, Festplatte, Netzwerk) liefert unvorhersehbare Eingaben.
  • Disk-I/O-Timing — Das genaue Timing von Lese-/Schreibvorgängen variiert durch mechanische und elektronische Faktoren.
  • Hardware RNG — Moderne CPUs (Intel RDRAND, AMD) enthalten On-Chip-Zufallszahlengeneratoren.
  • Boot-Zeit-Entropie — Manche Systeme speichern Entropie über Neustarts hinweg (/var/lib/systemd/random-seed unter Linux).

Das OS mischt diese Quellen mit kryptografischen Primitive in einen Entropiepool und nutzt den Pool dann zum Seeden seines CSPRNG. Auf modernen Linux-Kernels (5.18+) blockiert /dev/urandom, bis beim Booten genügend Entropie gesammelt wurde, und blockiert danach nie wieder.

Browser-Entropie (crypto.getRandomValues)​

Wenn du ein webbasiertes Tool wie den Generator von SafeSeed verwendest, wird die Browser-API crypto.getRandomValues() genutzt. Diese delegiert an den CSPRNG des Betriebssystems:

  • Chrome: Delegiert an OS-CSPRNG (BoringSSL).
  • Firefox: Delegiert an OS-CSPRNG (NSS).
  • Safari: Delegiert an OS-CSPRNG (CommonCrypto).

Dies gilt als sicher für die Schlüsselerzeugung, sofern das zugrunde liegende OS sicher ist. Die Hauptsorge ist der Betrieb in einer Umgebung, in der der OS-CSPRNG kompromittiert sein könnte (z. B. eine virtuelle Maschine mit unzureichenden Entropiequellen oder ein kompromittiertes Betriebssystem).

Hardware-Wallet-Entropie​

Hardware-Wallets verwenden On-Chip-True-Random-Number-Generatoren:

  • Ledger (Secure Element ST33): Nutzt den TRNG des ST33-Chips, der analoges Rauschen sampelt. Die Ausgabe durchläuft vor der Nutzung NIST SP 800-90B-Gesundheitstests.
  • Trezor: Nutzt den Hardware-RNG des STM32-Chips. Trezor unterstützt außerdem das Mischen von durch Nutzer bereitgestellter Würfelwurf-Entropie.
  • Coldcard: Nutzt den TRNG des Secure Elements ATECC608A plus den Hardware-RNG des MCU und mischt beide Quellen.

Würfelwurf-Entropie​

Manuelles Würfeln ist die transparenteste Methode zur Entropieerzeugung:

  • Ein fairer sechsseitiger Würfel erzeugt log2(6) = 2.585 Bit Entropie pro Wurf.
  • 100 Würfe erzeugen ungefähr 258,5 Bit Entropie, genug für eine 24-Wörter-Seed Phrase.
  • Der Nutzer kann die Zufälligkeit physisch verifizieren (faire Würfel, faire Würfe, keine Manipulation).

Fairness von Würfeln verifizieren:

  • Nutze präzise Casino-Würfel (scharfe Kanten, nicht abgerundet).
  • Würfle auf einer harten, ebenen Fläche mit Rückwand.
  • Würfel nicht "platzieren", sondern frei rollen lassen.
  • Jedes Ergebnis sofort und in Reihenfolge notieren.
SafeSeed Tool

Der SafeSeed Seed Phrase Generator ermöglicht es dir, deine eigene Entropie (z. B. Würfelwurfergebnisse) einzugeben, um eine BIP-39-Seed Phrase zu erzeugen. So kannst du die Zufallsquelle verifizieren und gleichzeitig von der korrekten BIP-39-Implementierung des Tools profitieren. Nutze das Tool für maximale Sicherheit offline, siehe unseren Leitfaden zur Offline-Schlüsselerzeugung.

Zufälligkeit testen und verifizieren​

NIST Statistical Test Suite​

NIST SP 800-22 definiert eine Reihe statistischer Tests zur Bewertung von Zufallszahlengeneratoren:

  • Frequency test — Gibt es ungefähr gleich viele 0en und 1en?
  • Block frequency test — Sind Unterblöcke von Bits ungefähr gleich verteilt?
  • Runs test — Haben Folgen aufeinanderfolgender identischer Bits (Runs) die erwartete Länge?
  • Longest run test — Liegt der längste Run innerhalb der erwarteten Grenzen?
  • Matrix rank test — Folgen binäre Matrixränge den erwarteten Verteilungen?
  • Spectral test — Zeigt die DFT der Bitsequenz die erwarteten Eigenschaften?

Diese Tests können Verzerrungen und Muster erkennen, aber nicht beweisen, dass ein Generator sicher ist. Sie können nur Ausfälle erkennen.

Dieharder Test Suite​

Eine umfassendere statistische Testbatterie, die die ursprünglichen Diehard-Tests plus zusätzliche Tests enthält. Als Open-Source-Software unter Linux verfügbar.

Praktische Verifikation für Nutzer​

Die meisten Nutzer können keine NIST-Test-Suites ausführen. Praktische Verifikationsschritte:

  1. Quellcode-Verifikation — Verwendet das Tool crypto.getRandomValues(), os.urandom() oder einen Hardware-RNG? Prüfe den Quellcode.
  2. Cross-Generation-Test — Erzeuge mehrere Seed Phrases und verifiziere, dass sie jedes Mal unterschiedlich sind.
  3. Entropieanzeige — Manche Tools zeigen die Rohentropie; prüfe, ob sie zufällig aussieht (keine offensichtlichen Muster).
  4. Open-Source-Audit — Ist das Tool Open Source und wurde es auditiert?

Entropiequellen mischen​

Best Practice für hochsichere Schlüsselerzeugung ist das Mischen mehrerer Entropiequellen:

Final Entropy = Hash(Hardware RNG output || OS CSPRNG output || User dice rolls || Timing data)

Das Mischen von Quellen stellt sicher, dass die finale Ausgabe selbst dann sicher bleibt, wenn eine Quelle kompromittiert oder verzerrt ist, solange mindestens eine Quelle genügend Entropie liefert. So gehen gut designte Hardware-Wallets und Tools zur Schlüsselerzeugung vor.

XOR-Mischung​

Eine einfache Mischmethode ist XOR. Wenn du 256 Bit aus Quelle A und 256 Bit aus Quelle B hast:

Mixed = A XOR B

Wenn entweder A oder B wirklich zufällig ist, ist das Ergebnis wirklich zufällig. Wenn beide verzerrt, aber unabhängig sind, ist das Ergebnis weniger verzerrt als jede einzelne Quelle.

Hash-Mischung​

Um Quellen unterschiedlicher Länge oder Qualität zu mischen, hashe sie zusammen:

Mixed = SHA-256(Source_A || Source_B || Source_C)

Die Hash-Funktion wirkt als Entropie-Extraktor und erzeugt eine gleichverteilte Ausgabe unabhängig vom Eingabeformat.

Entropie in Multi-Signature-Setups​

Multi-Signature-Wallets bieten eine Form von Entropie-Redundanz: Selbst wenn ein Schlüssel mit schwacher Entropie erzeugt wurde, muss der Angreifer zusätzlich die anderen Schlüssel kompromittieren. Ein 2-von-3-Multisig, bei dem jeder Schlüssel unabhängig erzeugt wird, bietet Sicherheit entsprechend dem stärksten Schlüssel, nicht dem schwächsten.

Das ist ein starkes Argument für Multi-Signature-Setups bei der Aufbewahrung hoher Werte.

FAQ​

Was ist Entropie bei Kryptowährungen?​

Entropie ist das Maß für Zufälligkeit oder Unvorhersehbarkeit in den Daten, die zur Erzeugung kryptografischer Schlüssel verwendet werden. Bei Kryptowährungen hängt die Sicherheit deiner privaten Schlüssel und Seed Phrases vollständig von ausreichender Entropie ab. Ein 256-Bit-Schlüssel sollte 256 Bit echte Zufälligkeit enthalten. Ist die Entropie geringer, wird der Schlüssel erratbar.

Wie viel Entropie brauche ich für eine sichere Wallet?​

Eine 12-Wörter-BIP-39-Seed Phrase bietet 128 Bit Entropie, und eine 24-Wörter-Phrase bietet 256 Bit. Beide gelten mit aktueller Technologie als sicher gegen Brute-Force-Angriffe. Für die langfristige Aufbewahrung hoher Werte werden 256 Bit (24 Wörter) empfohlen, um eine maximale Sicherheitsreserve zu bieten.

Ist Math.random() sicher für die Erzeugung von Krypto-Schlüsseln?​

Absolut nicht. Math.random() und ähnliche nicht-kryptografische PRNGs (Pythons random, Cs rand()) sind deterministisch, vorhersagbar und haben geringe Entropie. Sie dürfen niemals für kryptografische Schlüsselerzeugung verwendet werden. Nutze immer crypto.getRandomValues() in Browsern, os.urandom() in Python oder einen Hardware-Zufallszahlengenerator.

Kann ich meine eigene Entropie erzeugen, indem ich mir Zufallszahlen ausdenke?​

Nein. Menschen sind notorisch schlecht darin, Zufallszahlen zu erzeugen. Studien zeigen konsistent, dass vom Menschen gewählte "zufällige" Sequenzen deutlich weniger Entropie haben, als sie erscheinen lassen. Nutze stattdessen einen physikalischen Prozess (Würfel, Hardware RNG) oder einen kryptografisch sicheren Software-RNG.

Wie überprüfe ich, ob der Zufallszahlengenerator meiner Wallet sicher ist?​

Prüfe den Quellcode der Wallet (falls Open Source), um zu verifizieren, dass sie einen CSPRNG oder Hardware-TRNG verwendet. Suche nach Aufrufen von crypto.getRandomValues(), os.urandom() oder Hardware-RNG-APIs. Bei Hardware-Wallets prüfe die Sicherheitsdokumentation des Herstellers und Auditberichte von Drittparteien.

Was ist der "blockchain bandit" und was lehrt er über Entropie?​

Der "blockchain bandit" ist ein Angreifer, der systematisch Kryptowährung aus Wallets mit schwachen privaten Schlüsseln gestohlen hat (z. B. die Zahl 1, 2, 3 oder aus einfachen Passwörtern abgeleitete Schlüssel). Das zeigte, dass Angreifer Schlüssel mit niedriger Entropie aktiv enumerieren und alle gefundenen Gelder abschöpfen. Es unterstreicht die kritische Bedeutung von Zufallszahlengenerierung mit hoher Entropie.

Sind Zufallszahlengeneratoren in Hardware-Wallets vertrauenswürdig?​

TRNGs in Hardware-Wallets sind im Allgemeinen vertrauenswürdig, stellen aber einen einzelnen Vertrauenspunkt dar. Für maximale Sicherheit kannst du die Ausgabe des Hardware RNG mit vom Nutzer bereitgestellter Entropie (Würfelwürfe) mischen. Einige Hardware-Wallets (wie Trezor und Coldcard) unterstützen dieses Mischen nativ. So bleibt der resultierende Schlüssel sicher, selbst wenn der Hardware RNG kompromittiert ist.

Beeinflusst das Betriebssystem (Linux, macOS, Windows) die Schlüsselsicherheit?​

Ja. Qualität und Implementierung des OS-CSPRNG beeinflussen die Schlüsselsicherheit. Moderne Versionen von Linux, macOS und Windows bieten alle kryptografisch sichere Zufallszahlengeneratoren (/dev/urandom, arc4random, BCryptGenRandom). Der Debian-OpenSSL-Bug von 2006-2008 hat jedoch gezeigt, dass Schwachstellen auf OS-Ebene die Entropie katastrophal reduzieren können. Halte dein OS aktuell und verwende gut auditierte Software.

Verwandte Leitfäden​