Kryptografisch sichere PRNGs

Ein CSPRNG muss Folgendes erfüllen: (1) Next-Bit-Unvorhersagbarkeit — selbst bei Kenntnis aller vorherigen Bits darf das nächste Bit nicht mit einer Wahrscheinlichkeit von mehr als 1/2 + negligible vorhergesagt werden können. (2) Resistenz gegen Zustandskompromittierung — das Erlernen des aktuellen Zustands darf keine Informationen über frühere Ausgaben preisgeben.

Linux /dev/urandom verwendet einen aus dem Entropie-Pool gestarteten CSPRNG. Nach der ersten Initialisierung (128 Bit Entropie) kann er auch dann sicher verwendet werden, wenn der Pool „leer“ ist – der CSPRNG verwaltet seinen eigenen internen Zustand. getrandom() ist das moderne Äquivalent auf Systemaufrufebene.

Der Linux-Kernel 5.17+ hat seinen CSPRNG durch ein auf ChaCha20 basierendes Design ersetzt. ChaCha20 ist schnell (keine Hardwarebeschleunigung erforderlich), bietet 256-Bit-Sicherheit und verfügt über einen gut verstandenen Sicherheitsnachweis. Die Nonce ist der Zähler; der Schlüssel stammt aus dem Entropie-Pool.

Fortuna (Ferguson & Schneier, 2003) ist ein CSPRNG-Design, das 32 Entropie-Pools verwaltet und kontinuierlich Entropie sammelt. Der Generator wird aus den Pools neu initialisiert, sobald diese sich füllen. Er ist widerstandsfähig gegen Angriffe durch Zurücksetzen des RNG und gegen Angriffe durch teilweise Offenlegung des Zustands.

NIST SP 800-90A enthielt ursprünglich DUAL_EC_DRBG, das auf elliptischen Kurven basiert. Aus den Snowden-Dokumenten ging hervor, dass die NSA eine Hintertür eingefügt hatte: Die EC-Punkte wurden so gewählt, dass die NSA die Ausgabe aus jedem Seed vorhersagen konnte. Verwenden Sie DUAL_EC_DRBG niemals. NIST entfernte es 2014.

CTR_DRBG (NIST SP 800-90A) verwendet AES im Zählermodus als CSPRNG. Seed = 256-Bit-Schlüssel + 128-Bit-Nonce. Jeder Aufruf erhöht den Zähler. Weit verbreitet implementiert in OpenSSL, BoringSSL und Windows BCrypt. Auf CPUs mit AES-NI hardwarebeschleunigt.

HASH_DRBG verwendet iterativ eine Hashfunktion (SHA-256) zusammen mit einem Seed-Wert. HMAC_DRBG verwendet HMAC zum Mischen. HMAC_DRBG ist einfacher korrekt zu implementieren und wird in vielen eingebetteten Systemen verwendet (mbedTLS, WolfSSL).

Auch CSPRNGs müssen regelmäßig neu initialisiert werden. CTR_DRBG hat ein Intervall von 2^48 Anforderungen für die Neuinitalisierung. Fortuna wird aus seinen Entropie-Pools neu initialisiert. Manuelle Neuinitalisierung: Fügen Sie dem Zustand des CSPRNG beim Start und nach fork() frische Entropie (getrandom-Bytes) hinzu.

Wenn ein Prozess einen Fork ausführt, übernehmen sowohl der übergeordnete Prozess als auch der Kindprozess denselben CSPRNG-Zustand – sie erzeugen identische Ausgaben. Lösung: Rufen Sie unmittelbar nach fork() getrandom() auf, um den Zustand neu zu initialisieren. OpenSSL erledigt dies in aktuellen Versionen automatisch über pthread_atfork().

import secrets key = secrets.token_bytes(32) # 256-bit key nonce = secrets.token_bytes(12) # 96-bit nonce for AES-GCM pin = secrets.randbelow(10**6) # 6-digit PIN # Verwenden Sie das Modul random niemals für Kryptografie

window.crypto.getRandomValues(typedArray) ist der CSPRNG des Browsers. Er ruft die Entropiequelle des Betriebssystems auf. Er wird von der WebCrypto API zur Schlüsselerzeugung verwendet. Verwenden Sie Math.random() niemals für sicherheitsrelevante Zwecke – es handelt sich um einen nicht kryptografischen PRNG, der mit der Systemzeit initialisiert wird.

Welches Python-Modul sollten Sie verwenden, um kryptografisch sichere Zufallsbytes zu erzeugen?

CSPRNGs wie ChaCha20, CTR_DRBG und Fortuna erzeugen aus Entropie-Seeds nicht vorhersehbare Ausgaben. Vermeiden Sie DUAL_EC_DRBG, random.random() und Math.random(). Verwenden Sie secrets (Python) oder window.crypto (Browser). Als Nächstes: Fehler bei der Entropie in der Praxis.