Bezpieczne generowanie kluczy, nonce’ów i IV

Trzy różne wartości kryptograficzne wymagają bezpiecznego generowania: (1) Klucze — długotrwałe, muszą być nieprzewidywalne i tajne. (2) IV — używane dla każdej wiadomości, mogą być publiczne, ale muszą być nieprzewidywalne (CBC) lub unikatowe (GCM). (3) Nonce — muszą być unikatowe przy każdym użyciu, ale nie muszą być losowe.

AES-128: secrets.token_bytes(16). AES-256: secrets.token_bytes(32). ChaCha20: secrets.token_bytes(32). Nigdy nie należy wyprowadzać kluczy z haseł bez użycia KDF (PBKDF2/Argon2). Nie należy ponownie używać kluczy z różnymi algorytmami ani do różnych celów.

from cryptography.hazmat.primitives.asymmetric import ec, rsa rsa_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) ec_key = ec.generate_private_key(ec.SECP256R1()) # The library handles entropy sourcing internally

AES-CBC wymaga równomiernie losowego 16-bajtowego IV dla każdej wiadomości. Nigdy nie należy ponownie używać IV z tym samym kluczem. Nie należy używać licznika jako IV w trybie CBC. Należy wygenerować: iv = os.urandom(16). IV należy dołączyć na początku tekstu zaszyfrowanego — nie musi być tajny, a jedynie nieprzewidywalny.

AES-GCM wymaga unikatowego 96-bitowego nonce dla każdej pary (klucz, wiadomość). Ponowne użycie nonce katastrofalnie narusza bezpieczeństwo GCM: atakujący odzyskuje klucz uwierzytelniania i może fałszować wiadomości. Należy używać losowego nonce o długości 12 bajtów (granica urodzinowa przy 2^32 wiadomościach) albo licznika.

W przypadku szyfrowania dużej liczby danych jednym kluczem należy utrzymywać trwały licznik dla każdego klucza. nonce = counter.to_bytes(12, "big"). Po każdym szyfrowaniu należy zwiększyć licznik. Licznik trzeba zapisywać w trwałej pamięci — zresetowanie go po ponownym uruchomieniu powoduje ponowne użycie nonce.

AES-GCM-SIV i Deoxys-II są odporne na niewłaściwe użycie nonce: ponowne użycie nonce obniża bezpieczeństwo do poziomu szyfrowania deterministycznego (nie dochodzi do wycieku klucza uwierzytelniania). Są zalecane, gdy trudno zagwarantować unikatowość nonce (systemy rozproszone, scenariusze awarii i ponownego uruchomienia).

Nie należy bezpośrednio używać surowego materiału kluczowego do wielu celów. Należy wyprowadzać klucze przeznaczone do konkretnych celów: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Dla każdego celu należy używać innej wartości info.

Klucze przeznaczone dla konkretnej sesji należy wyprowadzać ze wspólnego sekretu (np. wyniku ECDH) za pomocą HKDF. TLS 1.3 wyprowadza oddzielne klucze klienta i serwera dla uzgadniania oraz danych aplikacji. Klucze sesyjne izolują skutki przejęcia: poznanie jednego klucza sesyjnego nie ujawnia niczego o pozostałych.

Aby bezpiecznie przechowywać klucz, należy opakować go za pomocą klucza szyfrowania kluczy (KEK), używając AES-KW (RFC 3394) lub AES-GCM. Opakowany klucz można przechowywać w bazie danych lub przesyłać. KEK jest przechowywany w HSM albo magazynie kluczy wspieranym sprzętowo (Android Keystore, Apple Secure Enclave).

Przed wdrożeniem należy sprawdzić: (1) wszystkie klucze pochodzą z os.urandom/secrets. (2) Brak kluczy/IV wpisanych na stałe w kodzie. (3) IV nigdy nie są ponownie używane z tym samym kluczem. (4) Nonce GCM są unikatowe dla każdej wiadomości. (5) Zdefiniowano harmonogram rotacji kluczy. (6) Wyprowadzanie kluczy używa HKDF z różnymi ciągami info.

Klucze wymagają rzeczywiście losowego generowania, IV w CBC wymagają losowości, a nonce w GCM wymagają unikatowości. Należy używać os.urandom/secrets, wyprowadzać klucze za pomocą HKDF i opakowywać je przy użyciu KEK. AEAD odporne na niewłaściwe użycie nonce chronią przed przypadkowym ponownym użyciem. Dalej: dowody z wiedzą zerową.