Pseudozufall und echter Zufall — Wie unterscheidet man sie eigentlich?

Gespräche über Zufallszahlen geraten schnell durcheinander, weil ganz unterschiedliche Dinge allesamt mit dem einen Wort „zufällig“ bezeichnet werden. Eine Zahlenfolge, die etwa mit Math.random() berechnet wird, und eine Folge, die aus physikalischen Phänomenen wie thermischem Rauschen oder Takt-Jitter gewonnen wird, sehen dem Erscheinungsbild nach beide einigermaßen verstreut aus.

In der Praxis führt es jedoch leicht zu Fehleinschätzungen wie diesen, wenn man diesen Unterschied unklar lässt.

• Eine Simulation soll reproduzierbar sein, aber die Ergebnisse schwanken jedes Mal
• Ein Token zum Zurücksetzen des Passworts wird mit leicht vorhersagbaren Zufallszahlen erzeugt
• Man besteht einen statistischen Test und hält das Ergebnis für „echten Zufall“
• Oder umgekehrt: Man hört „pseudo“ und hält das Ganze pauschal für gefährlich

Dieser Artikel erklärt, was Pseudozufall ist, was echter Zufall ist und wie man beides unterscheidet — in einer Form, die sich in der Praxis leicht anwenden lässt. Der Schwerpunkt liegt dabei nicht auf dem Erscheinungsbild der Ausgabe, sondern auf der Konstruktion des Generators.

Der Inhalt dieses Artikels stützt sich auf offizielle Dokumente von NIST, IETF, Betriebssystemen und Programmiersprachen, die mit Stand April 2026 verfügbar waren.

Inhaltsverzeichnis

1. Das Fazit zuerst (in aller Kürze)
2. Was dieser Artikel unter „Pseudozufall“ und „echtem Zufall“ versteht
3. Zunächst eine Ein-Seiten-Übersicht
   • 3.1. Beziehungsdiagramm
   • 3.2. Die kürzeste Begriffsübersicht
4. Was ist Pseudozufall?
   • 4.1. Kurz gesagt
   • 4.2. Gewöhnliche PRNGs und CSPRNGs getrennt betrachten
5. Was ist echter Zufall?
   • 5.1. Kurz gesagt
   • 5.2. Auch physikalischer Zufall wird nicht zwangsläufig unverändert verwendet
6. Was unterscheidet sich
   • 6.1. Erzeugungsquelle
   • 6.2. Reproduzierbarkeit
   • 6.3. Vorhersagbarkeit
   • 6.4. Geschwindigkeit und Betrieb
7. Wie unterscheidet man sie
   • 7.1. Anhand der Ausgabe allein lässt sich das grundsätzlich nicht entscheiden
   • 7.2. Zuerst zählt die Konstruktion des Generators
   • 7.3. Als Nächstes: mit statistischen Tests nach offensichtlichen Mängeln suchen
   • 7.4. Bei Sicherheitsanwendungen aus Angreiferperspektive betrachten
8. Was je nach Einsatzzweck zu verwenden ist
   • 8.1. Minimale Anwendungsbeispiele
9. Häufige Missverständnisse
10. Entscheidungstabelle für den Praxisalltag
11. Zusammenfassung
12. Quellen

1. Das Fazit zuerst (in aller Kürze)

Vorab, recht grob formuliert, aber praxistauglich ausgedrückt:

• Pseudozufall ist eine Zahlenfolge, die deterministisch aus einem internen Zustand und einem Algorithmus erzeugt wird
• Echter Zufall ist eine Zahlenfolge, deren Entropiequelle ein physikalisches Phänomen wie thermisches Rauschen oder Jitter ist
• Allerdings geben viele der in der Praxis genutzten sicheren Zufalls-APIs nicht den physikalischen Zufall direkt zurück, sondern einen mit einer Entropiequelle geseedeten DRBG / CSPRNG
• Man kann sie also nicht allein daran unterscheiden, ob es zufällig aussieht. Zu betrachten sind die Konstruktion des Generators, wie der Seed eingebracht wird, das Reseeding und die Health-Tests
• Bei Simulationen und reproduzierbaren Tests ist die Reproduzierbarkeit von Pseudozufall ein Vorteil
• Für Sicherheitszwecke wie Schlüssel, Token und Nonces ist es grundlegend, die vom Betriebssystem oder von der Sprache bereitgestellte sichere Zufalls-API zu verwenden

Kurz gesagt: Trennt man zunächst diese drei Fragen, liegt man selten falsch.

1. Geht es um einen gewöhnlichen PRNG?
2. Geht es um einen kryptografischen PRNG / CSPRNG / DRBG?
3. Geht es um einen NRBG / TRNG mit physikalischer Entropiequelle?

2. Was dieser Artikel unter „Pseudozufall“ und „echtem Zufall“ versteht

Bei diesem Thema ist das bloße Wort „Zufallszahl“ zu weit gefasst. Deshalb legen wir die Bedeutungen zuerst fest.

• Pseudozufall (PRNG): eine Zahlenfolge, die nach einem deterministischen Verfahren aus einem Seed und einem internen Zustand erzeugt wird. Unter denselben Bedingungen kommt dieselbe Folge heraus
• Kryptografischer Pseudozufall (CSPRNG / DRBG): eine Art von Pseudozufall, bei der jedoch die Unvorhersagbarkeit im Vordergrund steht. NIST SP 800-90A definiert diesen deterministic random bit generator
• Echter Zufall: In der Alltagssprache ist damit meist „echter Zufall“ oder „physikalischer Zufall“ gemeint. Bei NIST kommt dem der Begriff NRBG (non-deterministic random bit generator) am nächsten — beschrieben als ein Generator, der stets auf eine Entropiequelle zugreift und im Normalbetrieb eine Ausgabe mit voller Entropie liefert

Da sich die Bezeichnungen je nach Fachbereich unterscheiden, legen wir vorab auch die Entsprechung zwischen Alltagssprache und Normenterminologie fest. Im Folgenden verwenden wir die Bezeichnung aus der linken Spalte.

Zwei Ergänzungen dazu.

• Die von NIST SP 800-90A / 90B / 90C verwendeten Begriffe sind DRBG, NRBG und entropy source. CSPRNG und TRNG sind keine Normbegriffe, sondern in der Praxis und der Fachliteratur weit verbreitete Bezeichnungen
• Im japanischen Original wurden für „Pseudozufall“ zwei unterschiedliche Schreibweisen verwendet, die im Original vereinheitlicht wurden; nur die Titel der Quellendokumente blieben im Original erhalten

Wichtig ist hier, dass Pseudozufall und unsicherer Zufall nicht dasselbe sind.

Ein schneller PRNG wie ein linearer Kongruenzgenerator oder ein einfacher xorshift und ein CSPRNG wie CTR_DRBG oder HMAC_DRBG sind zum Beispiel beide deterministisch — doch ihre sicherheitstechnische Bedeutung ist sehr unterschiedlich.

3. Zunächst eine Ein-Seiten-Übersicht

3.1. Beziehungsdiagramm

Am schnellsten versteht man die Lage der Begriffe zueinander, wenn man sie auf einen Blick sieht.

flowchart LR
    NOISE["Physikalisches Phänomen<br/>thermisches Rauschen, Jitter usw."] --> ENT["Entropiequelle"]
    ENT --> SEED["Seed / Reseed"]
    SEED --> DRBG["DRBG / CSPRNG<br/>erzeugt Zufallszahlen schnell"]
    DRBG --> API["Von OS / Bibliothek zurückgegebene Zufallszahl"]

    STATE["Interner Zustand + Formel"] --> PRNG["Gewöhnlicher PRNG"]
    PRNG --> OUT["Zufällig wirkende Zahlenfolge"]

Wichtig ist hier, dass die Ausgabe der „sicheren Zufalls-API“, die eine Anwendung erhält, sich etwas sowohl vom gewöhnlichen PRNG rechts als auch vom reinen physikalischen Rauschen links unterscheidet.

Viele Implementierungen seeden bzw. reseeden mit der Entropiequelle auf der linken Seite und geben anschließend Werte zurück, die mit einem DRBG / CSPRNG schnell erzeugt werden. NIST SP 800-90B und 800-90C sind genau die Dokumente, die diese Konstruktion aus Entropiequelle + deterministischem Generator beschreiben.

3.2. Die kürzeste Begriffsübersicht

Zum kürzesten Merken:

• Ein gewöhnlicher PRNG ist „Zufall, den man reproduzieren kann“
• Ein CSPRNG ist „Zufall, der reproduzierbar ist, aber von außen schwer vorherzusagen sein soll“
• Echter Zufall ist „Zufall, der Entropie aus physikalischen Phänomenen gewinnt“

4. Was ist Pseudozufall?

4.1. Kurz gesagt

Pseudozufall berechnet, während er den internen Zustand fortlaufend aktualisiert, eine „zufällig wirkende Zahlenfolge“.

Gibt man denselben Seed ein, verwendet denselben Algorithmus und entnimmt gleich viele Werte, kommt dieselbe Wertefolge heraus. Das wirkt wie ein Nachteil, ist aber bei Simulation, Tests und Debugging gerade ein großer Vorteil.

Weil sich das Ergebnis reproduzieren lässt, sind Arbeitsweisen wie „bei diesem Seed tritt der Fehler auf“ oder „ich möchte das gestrige Ergebnis noch einmal vergleichen“ überhaupt erst möglich.

4.2. Gewöhnliche PRNGs und CSPRNGs getrennt betrachten

Das ist der Punkt, der am häufigsten missverstanden wird. Pseudozufall = unecht = darf nicht verwendet werden stimmt nicht.

NIST SP 800-90A definiert deterministic random bit generators, die auf Hashfunktionen und Blockchiffren aufbauen. Ein erheblicher Teil der für kryptografische Zwecke genutzten Zufallszahlen ist also selbst ein deterministischer Generator.

Der Unterschied liegt nicht in der bloßen „Zufälligkeit“, sondern in der Unvorhersagbarkeit aus Sicht eines Angreifers.

• Gewöhnlicher PRNG
  • schnell
  • leicht reproduzierbar
  • leicht vorhersagbar, sobald interner Zustand oder Seed bekannt werden
• CSPRNG / DRBG
  • ebenfalls deterministisch
  • aber so konzipiert, dass die Ausgabe schwer vorherzusagen ist, solange der interne Zustand unbekannt bleibt
  • für Sicherheitszwecke ist dies die richtige Wahl

Wer die Sicherheit allein daran bemisst, ob es Pseudozufall ist, liegt also fast immer falsch. Entscheidend ist, welcher Pseudozufallsgenerator es ist.

5. Was ist echter Zufall?

5.1. Kurz gesagt

Echter Zufall gewinnt Entropie aus physikalischer Unbestimmtheit — thermischem Rauschen, Oszillator-Jitter, Lawinenrauschen, Quantenphänomenen und Ähnlichem.

In der Alltagssprache spricht man von „echtem Zufall“ oder „physikalischem Zufall“. In der NIST-Terminologie kommt dem der Begriff NRBG am nächsten: ein Generator, der stets auf eine Entropiequelle zugreift und, solange er ordnungsgemäß funktioniert, eine Ausgabe mit voller Entropie liefert.

5.2. Auch physikalischer Zufall wird nicht zwangsläufig unverändert verwendet

Auch das ist wichtig. Nur weil es sich um echten Zufall handelt, heißt das nicht, dass die rohen Messwerte unverändert an die Anwendung weitergegeben werden.

Physikalische Quellen bringen einige praktische Schwierigkeiten mit sich.

• Es gibt eine Verzerrung (Bias)
• Sie werden von Temperatur, Stromversorgung, Ausfällen und Alterung beeinflusst
• Die rohe Ausgaberate ist mitunter nicht sehr hoch
• Ohne Health-Checks fällt ein defekter Zustand schwer auf

Deshalb legt NIST SP 800-90B Wert auf Konstruktionsprinzipien für Entropiequellen, das Konzept der Min-Entropie, Validierungstests und Health-Testing. Und in der Gesamtimplementierung kommt häufig die in NIST SP 800-90C beschriebene Konstruktion aus Entropiequelle + DRBG zum Einsatz.

Letztlich ist „echter Zufall“ kein geheimnisvolles Rohmaterial, sondern etwas, das man zusammen mit der physikalischen Quelle, ihrer Bewertung, Überwachung und Nachbearbeitung behandeln muss.

6. Was unterscheidet sich

Der Unterschied zwischen den Zufallsarten lässt sich nicht allein damit erfassen, ob es zufällig aussieht. Zumindest anhand dieser vier Achsen wird es klarer.

6.1. Erzeugungsquelle

• Pseudozufall: Algorithmus und interner Zustand
• Echter Zufall: physikalische Entropiequelle

Das ist der grundlegendste Unterschied.

6.2. Reproduzierbarkeit

• Pseudozufall: mit demselben Seed reproduzierbar
• Echter Zufall: eine erneute Erhebung unter denselben Bedingungen ergibt kaum dieselbe Wertefolge

Reproduzierbarkeit ist bei Tests eine Stärke, bei Ziehungen kann sie eine Schwäche sein.

6.3. Vorhersagbarkeit

• Gewöhnlicher PRNG: Sind Seed oder interner Zustand lesbar, lässt sich vieles im Voraus bestimmen
• CSPRNG: so konzipiert, dass ein Vorausschauen erschwert wird, solange der interne Zustand geschützt ist
• Echter Zufall: schwer vorherzusagen, solange die physikalische Quelle intakt ist — Sensorfehler oder Konstruktionsmängel sind jedoch ein eigenes Problem

Bei der Sicherheit ist diese Achse die wichtigste. Entscheidend ist nicht, wie verstreut die Ausgabe aussieht, sondern ob sich der nächste Wert erraten lässt.

6.4. Geschwindigkeit und Betrieb

• Pseudozufall: schnell, stabil, leicht zu implementieren
• Echter Zufall: erfordert Entropiesammlung und Überwachung, mit Einschränkungen bei Geschwindigkeit und Implementierungsaufwand

Deshalb ist in Produktivsystemen weder „nur echter Zufall“ noch „nur Pseudozufall“ die richtige Wahl, sondern ein mit physikalischer Entropie geseedeter CSPRNG ist am realistischsten.

7. Wie unterscheidet man sie

7.1. Anhand der Ausgabe allein lässt sich das grundsätzlich nicht entscheiden

Das ist die wichtigste Antwort überhaupt. Anhand einer endlichen Ausgabefolge lässt sich nicht feststellen, dies ist echter Zufall.

Der Grund ist einfach: Ein deterministisches Programm, das exakt dieselbe soeben beobachtete endliche Folge zurückgibt, lässt sich immer konstruieren. Im Extremfall genügt es, diese Folge in ein Array oder einen ROM einzubetten und der Reihe nach zurückzugeben.

Deshalb gilt: Es sieht natürlich aus, also ist es echt — das stimmt nicht. Auch NIST SP 800-22 stellt klar, dass statistische Tests nur ein erster Schritt sind und allein niemals die Gültigkeit eines Generators beweisen.

Umgekehrt gesagt: Ein guter CSPRNG wird gerade so konstruiert, dass er sich allein anhand der Ausgabe kaum von echtem Zufall unterscheiden lässt. Diese Ununterscheidbarkeit ist hier eher das Konstruktionsziel als ein Problem.

7.2. Zuerst zählt die Konstruktion des Generators

Die Antwort aus 7.1 lautete: „Mit der Ausgabe allein geht es nicht.“ Was betrachtet man also? Man betrachtet nicht die Ausgabe, sondern den Generator selbst.

Auch wenn zwei Folgen gleich gleichverteilt aussehen, kann die eine aus einem Seed berechnet und die andere aus einem physikalischen Phänomen gewonnen worden sein. Dieser Unterschied zeigt sich nicht, egal wie lange man die Folgen betrachtet — er wird erst durch die Prüfung der Entstehung sichtbar. Die Unterscheidung ist also keine Frage der „Beobachtung“, sondern der „Überprüfung“.

Zu prüfen sind folgende fünf Punkte.

• Welcher Erzeugungsalgorithmus wird verwendet
  • Ein einfacher PRNG oder ein DRBG / CSPRNG?
• Woher kommt der Seed
  • Ein fester Seed, die Uhrzeit, die PID?
  • Oder eine Entropiequelle des Betriebssystems?
• Wird reseedet
  • Nur einmal beim Start geseedet, dann nie wieder?
  • Oder auch im laufenden Betrieb erneut zugeführt?
• Gibt es eine Validierung der Entropiequelle
  • Min-Entropie-Bewertung
  • Health-Test
  • Fehlererkennung
• Welche API wird verwendet
  • Eine Eigenimplementierung?
  • Die Standard-API von OS oder Sprache?

Es ist nicht nötig, alle fünf Punkte vollständig zu klären. Gehen Sie sie von oben nach unten durch und stoppen Sie, sobald sich die Frage beantworten lässt. In der Praxis entscheiden meist nur zwei davon: der oberste Punkt, welcher Erzeugungsalgorithmus, und der unterste, welche API.

Aus dieser Perspektive lassen sich die meisten Fälle unterscheiden.

• Bei festem Seed kommt jedes Mal dieselbe Folge heraus → Pseudozufall
• Es gibt eine physikalische Entropiequelle, mit Validierung / Health-Tests als Voraussetzung → eine Konstruktion mit echter Zufallsquelle
• Es wird die sichere Zufalls-API des Betriebssystems aufgerufen → meist ein Hybrid aus physikalischer Entropie + CSPRNG

7.3. Als Nächstes: mit statistischen Tests nach offensichtlichen Mängeln suchen

Statistische Tests sind nicht überflüssig — im Gegenteil, sie sind wichtig. Ihre Rolle ist jedoch eher Fehlererkennung als Beweis.

Typischerweise werden unter anderem folgende Aspekte betrachtet.

• Verzerrung zwischen 0 und 1
• Verzerrung bei Runs
• Periodizität
• Korrelation
• Näherungsweise Entropie
• Lineare Komplexität

Häufig herangezogen werden dabei NIST SP 800-22 sowie, in Japan, der Minimal-Testsatz von CRYPTREC für Zufallszahlen. Diese eignen sich gut, um zu prüfen, ob die Folge eine seltsame Verzerrung oder Struktur aufweist.

Ein Bestehen bedeutet jedoch nicht echter Zufall. Ein gut konstruierter CSPRNG besteht solche Tests ganz normal, und umgekehrt kann sogar eine physikalische Zufallsquelle wegen Sensor-Verzerrung oder eines Defekts durchfallen.

Die Einordnung des Tests ist ungefähr so:

• Bestanden: Zunächst sind keine offensichtlichen Mängel erkennbar
• Durchgefallen: Mit hoher Wahrscheinlichkeit stimmt etwas nicht
• Damit als echt bewiesen: So weit reicht es nicht

7.4. Bei Sicherheitsanwendungen aus Angreiferperspektive betrachten

Bei Anwendungen wie Token zum Zurücksetzen des Passworts, Session-IDs, Nonces oder Schlüsselerzeugung genügt die Frage ist es echt? allein nicht.

Zu prüfen ist eigentlich, ob ein Angreifer den nächsten Wert vorhersagen kann.

Zum Beispiel:

• Es wird nur mit der aktuellen Uhrzeit geseedet
• Es werden lediglich Prozess-ID oder eine laufende Nummer eingemischt
• Eine Eigenimplementierung bewertet die Qualität des Seeds nicht
• Eine API aus der random-Familie wird zweckfremd für Sicherheitszwecke verwendet

Das lässt sich nicht dadurch verhindern, dass es plausibel aussieht.

Ein konkretes Beispiel dafür, was tatsächlich passieren kann, sei hier ausgeführt.

Angenommen, ein Token zum Zurücksetzen des Passworts wird mit einem PRNG erzeugt, der mit der aktuellen Uhrzeit geseedet wird. Der Angreifer fordert zunächst für sein eigenes Konto eine Zurücksetzung an und erhält so ein Token. Kennt er das Token und den Zeitpunkt der Anfrage, lässt sich der Kreis der möglichen Seeds auf wenige Sekunden davor und danach eingrenzen. Danach muss er nur noch für jeden Kandidaten denselben Algorithmus durchlaufen lassen und der Reihe nach prüfen, welcher Wert als Token des gewünschten Opfers erscheint.

Dabei bricht der Angreifer keine Kryptografie — er reproduziert lediglich den Generator selbst. Ob diese Zufallsfolge statistische Tests bestanden hätte, spielt dabei keine Rolle. Sobald sich die Kandidaten für den Seed aufzählen lassen, ist dieser Wert für den Angreifer kein Zufall mehr.

Dasselbe gilt für Session-IDs, Einladungscodes, Einmalpasswörter und temporäre Dateinamen in öffentlichen Ordnern. Alles, bei dem man nicht sagen kann, selbst bei Erraten entsteht kein nennenswerter Schaden, sollte mit einer sicheren Zufalls-API erzeugt werden.

Auch die IPA (Information-technology Promotion Agency, Japan) empfiehlt, sicherheitsrelevante APIs und vorhandene Bibliotheken zu kennen und auf leichtfertige Eigenimplementierungen zu verzichten. Für Python wird ausdrücklich empfohlen, das Modul secrets gegenüber random zu bevorzugen. In Java nimmt SecureRandom diese Rolle ein.

Letztlich zählt bei der Sicherheit weniger Pseudozufall oder echt? als vielmehr wird ein sicherer Seed / eine sichere Entropie und eine sichere API verwendet?.

8. Was je nach Einsatzzweck zu verwenden ist

Auf Implementierungsebene sind die soliden Entscheidungen diese:

• Natives Windows: BCryptGenRandom
• .NET: System.Security.Cryptography.RandomNumberGenerator
• Linux: getrandom()
• Python: secrets
• Java: SecureRandom

Microsoft Learn beschreibt, dass der Standardanbieter hinter Windows’ BCryptGenRandom dem CTR_DRBG nach NIST SP800-90 entspricht. Auch Linux’ getrandom() ist dafür dokumentiert, Zufallsbytes für cryptographic purposes liefern zu können. .NETs RandomNumberGenerator, Pythons secrets und Javas SecureRandom sind ebenfalls APIs, die jeweils mit Blick auf kryptografische Zwecke konzipiert wurden.

8.1. Minimale Anwendungsbeispiele

Eine bloße Übersicht bringt Sie noch nicht zum Handeln, daher folgen zwei repräsentative Beispiele in tatsächlicher Form. Beiden gemeinsam ist, dass der Seed nicht selbst bereitgestellt wird — die Beschaffung des Seeds ist Aufgabe der API.

In C# (.NET 8) verwenden Sie die statischen Methoden von System.Security.Cryptography.RandomNumberGenerator.

using System;
using System.Security.Cryptography;

// Eine ganze Zahl von 0 bis unter 100, ohne Verzerrung
int n = RandomNumberGenerator.GetInt32(0, 100);

// 32 Byte für ein Token, als URL-taugliche Zeichenkette
byte[] bytes = RandomNumberGenerator.GetBytes(32);
string token = Convert.ToBase64String(bytes)
    .Replace('+', '-')
    .Replace('/', '_')
    .TrimEnd('=');

GetInt32 wird verwendet, weil ein einfacher Rest bei Division einer Bytefolge durch den Bereich dazu führt, dass Randwerte bevorzugt auftreten. Wenn ein Bereich anzugeben ist, verwenden Sie diese Methode, statt selbst den Rest zu bilden.

In Python (ab 3.6) verwenden Sie das Modul secrets.

import secrets

# Ein sicheres, URL-taugliches Token
token = secrets.token_urlsafe(32)

# Eine ganze Zahl von 0 bis unter 100
n = secrets.randbelow(100)

Zum Vergleich: So sollten Sie es für denselben Zweck nicht schreiben.

import random

# Falsch: random ist ein auf Reproduzierbarkeit ausgelegter PRNG, nicht für Sicherheitszwecke gedacht
token = "".join(random.choices("abcdefghijklmnopqrstuvwxyz0123456789", k=32))

random und secrets liefern beide dem Aussehen nach verstreute Zeichenketten. Der Unterschied liegt nicht in der Ausgabe, sondern darin, woher der Zufall stammt. random ist ein auf Reproduzierbarkeit ausgelegter PRNG, der den Mersenne-Twister verwendet, und auch die offizielle Python-Dokumentation empfiehlt, für die Verwaltung von Geheimnissen secrets zu verwenden.

9. Häufige Missverständnisse

9.1. Wer statistische Tests besteht, ist echter Zufall

Falsch. Das belegt lediglich, dass keine offensichtliche Verzerrung erkennbar ist.

9.2. Echter Zufall ist immer sicher

Falsch. Defekte der physikalischen Quelle, Verzerrungen, Implementierungsmängel und fehlende Health-Tests können die Qualität beeinträchtigen.

9.3. Pseudozufall ist grundsätzlich gefährlich

Falsch. CSPRNG / DRBG bilden im Gegenteil den Kern der in der Praxis genutzten sicheren Zufalls-APIs.

9.4. Für Sicherheitszwecke sollte man nur rohen physikalischen Zufall direkt verwenden

Nicht unbedingt. In der Praxis ist die Kombination aus physikalischer Entropiequelle und CSPRNG üblich.

9.5. random oder Math.random() streuen ausreichend, also lassen sie sich für Token verwenden

Das ist der falsche Einsatzzweck. Sichtbare Streuung und Unvorhersagbarkeit gegenüber einem Angreifer sind zwei verschiedene Dinge.

10. Entscheidungstabelle für den Praxisalltag

Im Zweifel gehen Sie in dieser Reihenfolge vor:

1. Möchten Sie dasselbe Ergebnis reproduzieren?
   • Ja → gewöhnlicher PRNG
   • Nein → weiter
2. Wäre es ein Problem, wenn ein Angreifer den Wert vorhersagen könnte?
   • Ja → sichere Standard-RNG von OS / Sprache
   • Nein → Wahl nach Qualitätsanforderung und Geschwindigkeit
3. Ist Rechenschaftspflicht oder ein Audit der Zufallsquelle selbst erforderlich?
   • Ja → physikalische Zufallsquelle oder zertifizierten Dienst in Betracht ziehen
4. Möchten Sie es selbst implementieren?
   • Dieser Wunsch ist verständlich, aber Zufallszahlen sind fehleranfällig — verwenden Sie zunächst die Standard-API

Geht man diese Reihenfolge durch, findet man deutlich schneller eine Richtung, als wenn man allein über die Zweiteilung Pseudozufall oder echt? grübelt.

11. Zusammenfassung

Formuliert man den Unterschied zwischen Pseudozufall und echtem Zufall am gröbsten, aber praxistauglichsten, dann so:

• Pseudozufall wird durch Berechnung erzeugt
• Echter Zufall gewinnt Entropie aus physikalischen Phänomenen
• Aber in der Praxis dominieren bei sicheren Zufalls-APIs die Zwischenformen: Entropiequelle + CSPRNG

Zu betrachten ist also nicht das Erscheinungsbild, sondern die Konstruktion.

• Anhand der Ausgabe allein lässt sich nicht feststellen, ob etwas echt ist
• Statistische Tests helfen bei der Fehlererkennung, sind aber kein Beweis
• Bei der Sicherheit ist lässt es sich vorhersagen? die zentrale Frage
• Ist Reproduzierbarkeit gefragt, verwenden Sie einen PRNG; ist Unvorhersagbarkeit gefragt, die sichere Standard-RNG von OS oder Sprache

Betrachtet man es so, entkommt man dem groben Gegensatz ist Pseudozufall unecht?.

12. Quellen

1. NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators Das Grunddokument zum deterministic random bit generator.

2. NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation Ordnet die Konzepte von Entropiequelle, Validierung und Health-Testing.

3. NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions Ordnet die Konstruktion aus Entropiequelle + DRBG.

4. NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications Erklärt die Einordnung statistischer Tests. Wichtig: Tests sind ein erster Schritt, kein Beweis.

5. NIST Glossary: Non-deterministic Random Bit Generator (NRBG) Nützlich, um den NIST-Begriff zu prüfen, der „echtem Zufall“ am nächsten kommt.

6. RFC 4086: Randomness Requirements for Security Ordnet die Vorsichtsmaßnahmen rund um Zufallszahlen und Entropiequellen für Sicherheitszwecke.

7. Microsoft Learn: BCryptGenRandom function Beschreibt die sichere Zufalls-API von Windows und den CTR_DRBG des Standardanbieters.

8. Linux man page: getrandom(2) Die Zufalls-API von Linux, die sich für cryptographic purposes verwenden lässt.

9. Microsoft Learn: RandomNumberGenerator-Klasse Die kryptografisch starke RNG-API von .NET.

10. Python documentation: secrets — Generate secure random numbers for managing secrets Die Grundlagen für den Umgang mit Zufallszahlen für Sicherheitszwecke in Python.

11. Oracle Java Documentation: SecureRandom Fasst die sichere RNG von Java und das Konzept von Seed / Entropie zusammen.

12. IPA: Kapitel 3, Abschnitt 3 — Verwendung schwer zu brechender Kryptografie und von Pseudozufall Fasst die Bedeutung des Seeds, Tests und Hinweise zur API-Nutzung zusammen (auf Japanisch).

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist der Unterschied zwischen Pseudozufall und echtem Zufall (Echtzufall)?

Pseudozufall (PRNG) ist eine Zahlenfolge, die ein Algorithmus deterministisch aus einem Seed und einem internen Zustand erzeugt — unter denselben Bedingungen kommt dieselbe Folge heraus. Echter Zufall ist eine Zahlenfolge, deren Entropiequelle ein physikalisches Phänomen wie thermisches Rauschen oder Oszillator-Jitter ist; selbst unter denselben Bedingungen erneut erhoben, ergibt sich kaum dieselbe Wertefolge. Allerdings geben viele der in der Praxis genutzten sicheren Zufalls-APIs nicht den physikalischen Zufall direkt zurück, sondern verwenden eine Hybridkonstruktion: einen CSPRNG / DRBG, der mit einer physikalischen Entropiequelle geseedet wird.

Kann man am Output erkennen, ob es sich um Pseudozufall oder echten Zufall handelt?

Allein anhand einer endlichen Ausgabefolge lässt sich nicht mit Sicherheit feststellen, dass es sich um echten Zufall handelt. Denn es lässt sich immer ein deterministisches Programm konstruieren, das exakt dieselbe beobachtete Folge zurückgibt. Zur Unterscheidung ist es wesentlicher, statt auf das Erscheinungsbild der Ausgabe auf die Konstruktion des Generators zu schauen: Welcher Erzeugungsalgorithmus wird verwendet, woher kommt der Seed, wird reseedet, gibt es eine Prüfung der Entropiequelle (Min-Entropie-Bewertung oder Health-Test), und welche API wird verwendet.

Bedeutet das Bestehen statistischer Tests, dass es sich um echten Zufall handelt?

Nein. Die Rolle statistischer Tests ist eher Fehlererkennung als Beweis. Auch NIST SP 800-22 stellt klar, dass statistische Tests nur ein erster Schritt sind und allein niemals die Gültigkeit eines Generators beweisen. Ein gut konstruierter CSPRNG besteht solche Tests ganz normal, und umgekehrt kann selbst eine physikalische Zufallsquelle wegen Sensor-Verzerrung oder eines Defekts durchfallen. Die Einordnung lautet: Bestehen bedeutet, dass keine offensichtlichen Mängel erkennbar sind; Durchfallen bedeutet, dass mit hoher Wahrscheinlichkeit etwas nicht stimmt.

Welche Zufalls-API sollte man für Sicherheitszwecke verwenden?

Für Zwecke wie Schlüssel, Token, Nonces oder Session-IDs ist es grundlegend, die vom Betriebssystem oder von der Sprache bereitgestellte sichere Zufalls-API zu verwenden. Konkret: unter nativem Windows BCryptGenRandom, unter .NET System.Security.Cryptography.RandomNumberGenerator, unter Linux getrandom(), in Python das secrets-Modul und in Java SecureRandom. Eigenimplementierungen, die mit der aktuellen Uhrzeit oder der Prozess-ID geseedet werden, sowie die zweckfremde Nutzung von random-artigen APIs für Sicherheitszwecke sollten vermieden werden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.