Schlüssel, Nonces und IVs sicher erzeugen

Drei unterschiedliche kryptografische Werte müssen sicher erzeugt werden: (1) Schlüssel – langlebig, müssen unvorhersehbar und geheim sein. (2) IVs – pro Nachricht, dürfen öffentlich sein, müssen aber unvorhersehbar (CBC) oder eindeutig (GCM) sein. (3) Nonces – müssen pro Verwendung eindeutig sein und müssen nicht unbedingt zufällig sein.

AES-128: secrets.token_bytes(16). AES-256: secrets.token_bytes(32). ChaCha20: secrets.token_bytes(32). Leiten Sie Schlüssel niemals ohne KDF (PBKDF2/Argon2) aus Passwörtern ab. Verwenden Sie Schlüssel niemals für verschiedene Algorithmen oder Zwecke wieder.

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()) # Die Bibliothek übernimmt die Entropiebeschaffung intern

AES-CBC erfordert für jede Nachricht einen gleichverteilten zufälligen 16-Byte-IV. Verwenden Sie einen IV niemals mit demselben Schlüssel wieder. Verwenden Sie im CBC-Modus niemals einen Zähler als IV. Erzeugen Sie ihn mit: iv = os.urandom(16). Stellen Sie den IV dem Chiffretext voran – er muss nicht geheim, sondern nur unvorhersehbar sein.

AES-GCM erfordert für jedes Paar aus (Schlüssel, Nachricht) eine eindeutige 96-Bit-Nonce. Die Wiederverwendung einer Nonce zerstört die Sicherheit von GCM: Ein Angreifer kann den Authentifizierungsschlüssel rekonstruieren und Nachrichten fälschen. Verwenden Sie entweder eine zufällige 12-Byte-Nonce (Geburtstagsgrenze bei 2^32 Nachrichten) oder einen Zähler.

Für Verschlüsselung mit hohem Volumen und einem einzelnen Schlüssel: Führen Sie pro Schlüssel einen persistenten Zähler. nonce = counter.to_bytes(12, "big"). Erhöhen Sie den Zähler nach jeder Verschlüsselung. Speichern Sie den Zähler in einem persistenten Speicher – ein Zurücksetzen beim Neustart führt zu einer Wiederverwendung.

AES-GCM-SIV und Deoxys-II sind resistent gegen fehlerhafte Nonce-Verwendung: Die Wiederverwendung einer Nonce reduziert die Sicherheit auf die einer deterministischen Verschlüsselung (kein Verlust des Authentifizierungsschlüssels). Sie werden empfohlen, wenn die Eindeutigkeit von Nonces nur schwer garantiert werden kann (verteilte Systeme, Szenarien mit Absturz und Neustart).

Verwenden Sie rohes Schlüsselmaterial nicht direkt für mehrere Zwecke. Leiten Sie zweckgebundene Schlüssel ab: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Verwenden Sie für jeden Zweck einen anderen info-Wert.

Leiten Sie sitzungsspezifische Schlüssel mithilfe von HKDF aus einem gemeinsamen Geheimnis ab (z. B. aus einer ECDH-Ausgabe). TLS 1.3 leitet separate Client-/Server-Schlüssel für den Handshake und die Anwendungsdaten ab. Sitzungsschlüssel begrenzen die Auswirkungen einer Kompromittierung: Wenn ein Sitzungsschlüssel bekannt wird, erfahren Sie nichts über andere Sitzungen.

Um einen Schlüssel sicher zu speichern, verpacken Sie ihn mit einem Key Encryption Key (KEK) unter Verwendung von AES-KW (RFC 3394) oder AES-GCM. Der verpackte Schlüssel kann in einer Datenbank gespeichert oder übertragen werden. Der KEK wird in einem HSM oder einem hardwaregestützten Keystore gespeichert (Android Keystore, Apple Secure Enclave).

Prüfen Sie vor der Bereitstellung: (1) alle Schlüssel stammen aus os.urandom/secrets. (2) Keine fest codierten Schlüssel/IVs. (3) IVs werden niemals mit demselben Schlüssel wiederverwendet. (4) GCM-Nonces sind pro Nachricht eindeutig. (5) Ein Zeitplan für die Schlüsselrotation ist definiert. (6) Die Schlüsselableitung verwendet HKDF mit unterschiedlichen info-Zeichenfolgen.

Welche Folge hat die Wiederverwendung einer Nonce bei AES-GCM?

Schlüssel benötigen eine echte Zufallserzeugung; CBC-IVs benötigen Zufälligkeit; GCM-Nonces benötigen Eindeutigkeit. Verwenden Sie os.urandom/secrets, leiten Sie Schlüssel mit HKDF ab und verpacken Sie sie mit KEKs. AEADs mit Resistenz gegen fehlerhafte Nonce-Verwendung schützen vor versehentlicher Wiederverwendung. Als Nächstes: Zero-Knowledge-Beweise.