Kryptograficznie bezpieczne PRNG

CSPRNG musi spełniać następujące wymagania: (1) nieprzewidywalność następnego bitu — znając wszystkie wcześniejsze bity, nie można przewidzieć następnego z prawdopodobieństwem > 1/2 + wartość pomijalna. (2) odporność na rozszerzenie po kompromitacji stanu — poznanie bieżącego stanu nie ujawnia niczego o wcześniejszych danych wyjściowych.

Linux /dev/urandom używa CSPRNG inicjalizowanego na podstawie puli entropii. Po początkowej inicjalizacji (128 bitów entropii) można go bezpiecznie używać nawet wtedy, gdy pula jest „pusta” — CSPRNG utrzymuje własny stan wewnętrzny. getrandom() jest współczesnym odpowiednikiem wywołania systemowego.

Jądro Linux 5.17+ zastąpiło swój CSPRNG konstrukcją opartą na ChaCha20. ChaCha20 jest szybki (nie wymaga akceleracji sprzętowej), zapewnia bezpieczeństwo na poziomie 256 bitów i ma dobrze poznany dowód bezpieczeństwa. Nonce pełni funkcję licznika, a klucz pochodzi z puli entropii.

Fortuna (Ferguson & Schneier, 2003) to konstrukcja CSPRNG, która utrzymuje 32 pule entropii i stale gromadzi entropię. Generator jest ponownie inicjalizowany na podstawie pul w miarę ich zapełniania. Jest odporna na ataki polegające na zresetowaniu RNG oraz częściowym przejęciu stanu.

NIST SP 800-90A pierwotnie zawierał DUAL_EC_DRBG oparty na krzywych eliptycznych. Dokumenty Snowdena ujawniły, że NSA umieściła w nim backdoor: punkty krzywej eliptycznej dobrano tak, aby NSA mogła przewidywać dane wyjściowe na podstawie dowolnego ziarna. Nigdy nie należy używać DUAL_EC_DRBG. NIST usunął go w 2014 roku.

CTR_DRBG (NIST SP 800-90A) używa AES w trybie licznika jako CSPRNG. Ziarno = klucz 256-bitowy + nonce 128-bitowy. Każde wywołanie przesuwa licznik. Jest szeroko zaimplementowany w OpenSSL, BoringSSL i Windows BCrypt. Na procesorach z AES-NI korzysta z akceleracji sprzętowej.

HASH_DRBG wielokrotnie używa funkcji skrótu (SHA-256) wraz z wartością ziarna. HMAC_DRBG używa HMAC do mieszania danych. HMAC_DRBG jest prostszy do poprawnej implementacji i jest używany w wielu systemach wbudowanych (mbedTLS, WolfSSL).

Nawet CSPRNG muszą być okresowo ponownie inicjalizowane. CTR_DRBG ma interwał ponownej inicjalizacji wynoszący 2^48 żądań. Fortuna jest ponownie inicjalizowana na podstawie swoich pul entropii. Ręczna ponowna inicjalizacja: przy uruchamianiu oraz po fork() należy dodać do stanu CSPRNG świeżą entropię (bajty z getrandom).

Po utworzeniu procesu potomnego za pomocą fork() proces macierzysty i potomny dziedziczą ten sam stan CSPRNG — będą generować identyczne dane wyjściowe. Rozwiązanie: natychmiast po fork() wywołać getrandom(), aby ponownie zainicjalizować generator. W nowszych wersjach OpenSSL jest to obsługiwane automatycznie za pomocą 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 # Never use random module for cryptography

window.crypto.getRandomValues(typedArray) to przeglądarkowy CSPRNG. Wywołuje systemowe źródło entropii. Jest używany przez WebCrypto API do generowania kluczy. Nigdy nie należy używać Math.random() do celów bezpieczeństwa — jest to niekryptograficzny PRNG inicjalizowany na podstawie czasu systemowego.

Jakiego modułu Pythona należy użyć do generowania kryptograficznie losowych bajtów?

CSPRNG, takie jak ChaCha20, CTR_DRBG i Fortuna, generują nieprzewidywalne dane wyjściowe na podstawie ziaren entropii. Należy unikać DUAL_EC_DRBG, random.random() i Math.random(). Należy używać secrets (Python) lub window.crypto (przeglądarka). Dalej: rzeczywiste awarie entropii.