Générer des clés, des nonces et des IV en toute sécurité

Trois catégories distinctes de valeurs cryptographiques doivent être générées de manière sûre : (1) les clés — à longue durée de vie, elles doivent être imprévisibles et secrètes ; (2) les IV — propres à chaque message, ils peuvent être publics mais doivent être imprévisibles (CBC) ou uniques (GCM) ; (3) les nonces — ils doivent être uniques à chaque utilisation, mais peuvent être aléatoires ou non.

AES-128 : secrets.token_bytes(16). AES-256 : secrets.token_bytes(32). ChaCha20 : secrets.token_bytes(32). Ne dérivez jamais de clés à partir de mots de passe sans KDF (PBKDF2/Argon2). Ne réutilisez jamais des clés avec des algorithmes ou des usages différents.

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()) # La bibliothèque gère l’approvisionnement en entropie en interne

AES-CBC nécessite un IV uniformément aléatoire de 16 octets par message. Ne réutilisez jamais un IV avec la même clé. N’utilisez jamais un compteur comme IV en mode CBC. Générez-le ainsi : iv = os.urandom(16). Ajoutez l’IV au début du texte chiffré — il n’a pas besoin d’être secret, seulement imprévisible.

AES-GCM nécessite un nonce unique de 96 bits pour chaque paire (clé, message). La réutilisation d’un nonce compromet catastrophiquement GCM : l’attaquant récupère la clé d’authentification et peut forger des messages. Utilisez soit un nonce aléatoire de 12 octets (borne des anniversaires à 2^32 messages), soit un compteur.

Pour un chiffrement à gros volume avec une seule clé : maintenez un compteur persistant par clé. nonce = counter.to_bytes(12, "big"). Incrémentez le compteur après chaque chiffrement. Stockez le compteur dans un stockage persistant : une réinitialisation au redémarrage entraîne une réutilisation.

AES-GCM-SIV et Deoxys-II résistent à la mauvaise utilisation des nonces : la réutilisation d’un nonce dégrade la sécurité au niveau du chiffrement déterministe (aucune fuite de la clé d’authentification). Ils sont recommandés lorsque l’unicité des nonces est difficile à garantir (systèmes distribués, scénarios d’arrêt et de redémarrage après incident).

N’utilisez pas directement le matériau de clé brut à plusieurs fins. Dérivez des clés propres à chaque usage : from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Utilisez une valeur info différente pour chaque usage.

Dérivez des clés propres à chaque session à partir d’un secret partagé (par exemple, une sortie ECDH) à l’aide de HKDF. TLS 1.3 dérive des clés distinctes côté client et côté serveur pour l’établissement de la connexion et les données applicatives. Les clés de session isolent les compromissions : connaître une clé de session ne révèle rien sur les autres.

Pour stocker une clé en toute sécurité, encapsulez-la avec une clé de chiffrement de clés (KEK) au moyen de AES-KW (RFC 3394) ou AES-GCM. La clé encapsulée peut être stockée dans une base de données ou transmise. La KEK est stockée dans un HSM ou un magasin de clés protégé par le matériel (Android Keystore, Apple Secure Enclave).

Avant le déploiement, vérifiez : (1) toutes les clés proviennent de os.urandom/secrets ; (2) aucune clé ni aucun IV n’est codé en dur ; (3) les IV ne sont jamais réutilisés avec la même clé ; (4) les nonces GCM sont uniques pour chaque message ; (5) le calendrier de rotation des clés est défini ; (6) la dérivation des clés utilise HKDF avec des chaînes info distinctes.

Quelle est la conséquence de la réutilisation d’un nonce dans AES-GCM ?

Les clés nécessitent une génération véritablement aléatoire ; les IV de CBC nécessitent de l’aléa ; les nonces de GCM nécessitent l’unicité. Utilisez os.urandom/secrets, dérivez les clés avec HKDF et encapsulez-les avec des KEK. Les AEAD résistants à la mauvaise utilisation des nonces protègent contre les réutilisations accidentelles. Ensuite : les preuves à divulgation nulle de connaissance.