Chiffrement symétrique expliqué - AES, ChaCha20, AEAD, modes

Le chiffrement symétrique est la primitive cryptographique la plus utilisée dans les systèmes réels : TLS pour chiffrer le trafic après le handshake, chiffrement des disques et bases de données au repos, Signal pour les messages, Cosign pour les artefacts. Deux mots-clés en 2026 dominent : AES-GCM et ChaCha20-Poly1305. Tout le reste est soit historique, soit niche, soit dangereux. Ce guide explique les primitives, les modes d'opération (piège classique), les constructions AEAD, la gestion des nonces (source n°1 de bugs), la dérivation de clés et les bibliothèques à utiliser.

1. Rappel - qu'est-ce que le chiffrement symétrique

1.1 Principe

Alice et Bob partagent une clé secrète K. Pour communiquer :

• Alice chiffre son message m : c = Encrypt(K, m).
• Elle envoie c sur un canal public.
• Bob déchiffre : m = Decrypt(K, c).

Un attaquant qui voit c sans connaître K ne peut pas retrouver m (avec les bons choix).

1.2 Caractéristiques

• Rapide : des centaines de Mo/s en logiciel, des Go/s avec accélération hardware.
• Efficace pour volumes : chiffrer un bucket S3 de 500 Go se fait en secondes.
• Pas de distribution : Alice et Bob doivent déjà partager la clé avant de pouvoir l'utiliser.

Le problème de distribution des clés est résolu par la cryptographie asymétrique (voir qu'est-ce que la cryptographie).

1.3 Tailles de clé et sécurité

Règle 2026 : AES-128 minimum, AES-256 préférable pour données à longue durée de vie.

2. Les familles de chiffrement symétrique

2.1 Block ciphers

Chiffrent par blocs de taille fixe :

• Taille de bloc typique : 128 bits (16 octets).
• Exemples : AES, Twofish, Serpent, Camellia.
• Nécessitent un mode d'opération pour traiter des messages plus longs qu'un bloc.

2.2 Stream ciphers

Chiffrent byte par byte (ou bit par bit) :

• Produisent un flux pseudo-aléatoire XORé avec le plaintext.
• Plus naturels pour streaming et données en continu.
• Exemples : ChaCha20, Salsa20, RC4 (déprécié).

2.3 Différence pratique 2026

• Le dogme historique "block vs stream" s'est largement effacé.
• Les modes comme CTR transforment un block cipher en stream cipher.
• ChaCha20-Poly1305 et AES-GCM sont tous deux des constructions AEAD utilisées de manière interchangeable.

En pratique, on choisit en fonction du support hardware et de la bibliothèque, pas de la philosophie block vs stream.

3. AES - Advanced Encryption Standard

3.1 Origine

AES standardisé par NIST en 2001 (FIPS 197). Algorithme Rijndael (Joan Daemen, Vincent Rijmen) sélectionné parmi 15 candidats.

3.2 Structure (très simplifiée)

AES est un SPN (Substitution-Permutation Network) :

• Bloc de 128 bits.
• 10/12/14 rounds selon la clé (128/192/256 bits).
• Chaque round : SubBytes (substitution), ShiftRows (permutation), MixColumns (diffusion), AddRoundKey (XOR avec clé dérivée).

Tu n'as pas besoin de comprendre le détail pour bien l'utiliser. L'important est que :

• AES-128 et AES-256 sont tous deux considérés sûrs contre attaques classiques connues.
• AES-256 a plus de rounds (14 vs 10) donc marge de sécurité plus large.
• AES est intégré en hardware (AES-NI Intel depuis 2010, ARMv8, RISC-V Zkne). Performance proche du memcpy.

3.3 Attaques connues

Meilleures attaques en 2026 :

• AES-128 : 126 bits effectifs (attaque biclique, marginale).
• AES-256 : 254 bits effectifs.
• Aucune attaque pratique sur AES full-round avec implémentation correcte.

AES reste ultra-solide pour les prochaines décennies (hors scénario post-quantum où Grover divise par 2 → AES-256 garantit 128 bits effectifs, suffisant).

4. ChaCha20 - l'alternative moderne

4.1 Origine

Créé par Daniel Bernstein (2008). Variante de Salsa20 avec meilleur diffusion.

4.2 Structure

• Stream cipher : génère un flux pseudo-aléatoire.
• Clé 256 bits.
• Nonce 96 bits (IETF) ou 192 bits (XChaCha20).
• 20 rounds d'operations ARX (Add-Rotate-XOR).

4.3 Avantages sur AES

• Pas de table lookup : pas vulnérable aux timing attacks liées aux caches CPU (problème historique d'AES software).
• Rapide sans hardware : 2 à 3x plus rapide qu'AES software sans AES-NI. Utile sur mobile, IoT, embarqué.
• Implémentation simple : plus facile à implémenter correctement en constant-time.
• Utilisé dans : TLS 1.3, WireGuard, Signal, libsodium, SSH, Wireguard.

4.4 XChaCha20

Variante avec nonce étendu à 192 bits. Permet de générer les nonces aléatoirement sans risque de collision, ce qui est impraticable avec ChaCha20 standard (nonce 96 bits → risque de collision au bout de 2^48 messages).

5. Les modes d'opération - le piège classique

Un block cipher seul ne chiffre qu'un bloc (128 bits). Pour chiffrer un message plus long, il faut un mode. Le choix du mode est critique.

5.1 ECB - Electronic Codebook (dangereux)

Chaque bloc chiffré indépendamment avec la même clé.

c[i] = AES(K, m[i])

Problème : le même plaintext donne toujours le même ciphertext. Les patterns du message sont visibles dans le ciphertext.

L'exemple canonique : chiffrer une image d'un pingouin avec AES-ECB. Le pingouin reste parfaitement visible dans le ciphertext. Recherche "AES ECB penguin" pour l'illustration.

Usage : JAMAIS en prod. Si ton code utilise ECB, c'est un bug.

5.2 CBC - Cipher Block Chaining

Chaque bloc XORé avec le ciphertext du bloc précédent avant chiffrement :

c[0] = AES(K, m[0] XOR IV)
c[i] = AES(K, m[i] XOR c[i-1])

L'IV (Initialization Vector) doit être aléatoire et unique.

Avantages :

• Patterns dissimulés (contrairement à ECB).
• Standard historique.

Problèmes :

• Padding oracle attacks : si le serveur révèle par erreur que le padding est invalide (via message d'erreur, timing), l'attaquant peut déchiffrer le ciphertext byte par byte (CVE Vaudenay 2002, BEAST 2011, Lucky 13 2013, POODLE 2014).
• Pas d'authentification intégrée : sans MAC séparé, ciphertext malléable.
• Non parallélisable en chiffrement.
• Prédictibilité de l'IV ouvre des attaques (BEAST).

Usage : déprécié en l'absence d'authentification. Si absolument nécessaire, encrypt-then-MAC avec HMAC-SHA-256.

5.3 CTR - Counter Mode

Transforme un block cipher en stream cipher :

keystream[i] = AES(K, counter || nonce)
c[i] = m[i] XOR keystream[i]

• Counter unique par bloc.
• Nonce unique par message.

Avantages :

• Parallélisable.
• Pas de padding requis.
• Rapide.

Problèmes :

• Pas d'authentification.
• Nonce + counter ne doit JAMAIS être réutilisé avec la même clé (sinon keystream leak trivial).

Usage : rarement seul, souvent combiné en GCM pour AEAD.

5.4 GCM - Galois/Counter Mode (recommandé)

Combine CTR (chiffrement) + GHASH (authentification via Galois field) en une seule primitive AEAD :

AES-GCM.encrypt(key, nonce, plaintext, aad) -> (ciphertext, tag)

• Nonce : 96 bits (12 octets) recommandé.
• Tag : 128 bits d'authentification.
• AAD (Additional Authenticated Data) : données authentifiées mais non chiffrées (ex. headers HTTP).

Avantages :

• AEAD (chiffrement + authentification).
• Parallélisable.
• Hardware support (AES-NI + PCLMULQDQ sur x86).
• Standard moderne (TLS 1.2+, IPsec, SSH).

Pièges :

• Nonce réutilisé = catastrophe : si la même clé est utilisée avec le même nonce pour deux messages différents, l'attaquant récupère le XOR des plaintexts ET peut forger des messages authentifiés.

Usage : choix par défaut pour AEAD avec AES en 2026.

5.5 XTS - XEX-based Tweaked codebook mode with CipherText Stealing

Conçu spécifiquement pour le chiffrement de disques/volumes.

• Pas d'AEAD (pas de tag d'authentification).
• Résistant à la modification bloc par bloc (chaque bloc chiffré différemment selon sa position).
• Utilisé par : BitLocker, FileVault, LUKS/dm-crypt.

Usage : chiffrement de stockage uniquement. Jamais en communication réseau.

5.6 SIV / GCM-SIV - Synthetic IV (nonce misuse resistant)

Problème GCM : nonce réutilisé = catastrophe. SIV résout :

• Si nonce unique : sécurité équivalente à GCM.
• Si nonce réutilisé (accidentellement) : impact limité (révèle que le même plaintext a été chiffré, mais ne casse pas la clé).

AES-GCM-SIV (RFC 8452) : variant moderne de GCM, recommandé quand la génération de nonces uniques est difficile à garantir.

5.7 Récapitulatif modes

6. AEAD - Authenticated Encryption with Associated Data

6.1 Pourquoi AEAD

Chiffrement seul donne confidentialité mais pas intégrité. L'attaquant peut modifier le ciphertext (bit flipping) et provoquer une modification prédictible du plaintext après déchiffrement.

AEAD résout en combinant les deux en une primitive unique :

AEAD.encrypt(key, nonce, plaintext, aad) -> (ciphertext, tag)
AEAD.decrypt(key, nonce, ciphertext, tag, aad) -> plaintext OR failure

• Chiffrement intègre l'authentification.
• Les AAD (données authentifiées mais non chiffrées) sont typiquement les metadata (headers, IDs, timestamps).
• Échec de vérification du tag = décryptage refusé (pas de plaintext corrompu retourné).

6.2 AES-GCM

Standard dominant en 2026.

Exemple Python avec cryptography :

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
 
key = AESGCM.generate_key(bit_length=256)
nonce = os.urandom(12)  # 96 bits - jamais réutilisé avec cette clé
aesgcm = AESGCM(key)
 
plaintext = b"donnees sensibles"
aad = b"user_id=12345, timestamp=1720000000"
 
ciphertext = aesgcm.encrypt(nonce, plaintext, aad)
 
# Côté déchiffrement
plaintext_recovered = aesgcm.decrypt(nonce, ciphertext, aad)

Ce code est correct et sûr si le nonce est unique par message pour cette clé.

6.3 ChaCha20-Poly1305

Alternative performante.

Exemple Node.js :

const crypto = require('crypto');
 
const key = crypto.randomBytes(32);
const nonce = crypto.randomBytes(12);
const aad = Buffer.from('user_id=12345');
 
const cipher = crypto.createCipheriv('chacha20-poly1305', key, nonce, { authTagLength: 16 });
cipher.setAAD(aad);
const encrypted = Buffer.concat([cipher.update('donnees sensibles'), cipher.final()]);
const authTag = cipher.getAuthTag();
 
// Déchiffrement
const decipher = crypto.createDecipheriv('chacha20-poly1305', key, nonce, { authTagLength: 16 });
decipher.setAAD(aad);
decipher.setAuthTag(authTag);
const decrypted = Buffer.concat([decipher.update(encrypted), decipher.final()]);

6.4 libsodium - pourquoi c'est souvent meilleur

libsodium offre une API haut niveau qui élimine les pièges :

from nacl.secret import SecretBox
from nacl.utils import random
 
key = random(SecretBox.KEY_SIZE)
box = SecretBox(key)
encrypted = box.encrypt(b"donnees sensibles")
# Le nonce est généré automatiquement et stocké dans `encrypted`
decrypted = box.decrypt(encrypted)

Tu ne gères plus le nonce. libsodium le gère. Moins de surface de bug.

7. Nonces - la source numéro 1 de bugs

7.1 Pourquoi le nonce compte

Un nonce (number used once) garantit qu'un chiffrement de deux plaintexts identiques donne deux ciphertexts différents. Sans nonce unique, beaucoup d'attaques deviennent triviales.

7.2 Les 3 façons de gérer un nonce

• Compteur monotone : incrémenter un nombre à chaque chiffrement. Simple mais nécessite un état persistant.
• Aléatoire : générer un nonce aléatoire (96 ou 192 bits). Stateless mais collision possible après 2^48 messages pour 96 bits.
• Dérivé : combinaison d'un compteur et d'un identifiant unique.

7.3 GCM et nonce

• Nonce 96 bits recommandé.
• Risque de collision à 2^32 messages par clé (birthday bound sur 96 bits) - pour une durée de vie raisonnable, borner à environ 2^32 chiffrements par clé.
• Jamais réutiliser un nonce avec la même clé.

7.4 Incidents nonce célèbres

• OCB à clé courte : publication initiale avec nonce trop court a permis des attaques.
• WEP : IV de 24 bits réutilisés → casse complète du WPA en 2001.
• Nintendo Switch (2018) : reconstruction de clés via réutilisation de nonce.

7.5 Recommandation 2026

• Utiliser XChaCha20-Poly1305 si possible : nonce 192 bits, génération aléatoire sûre.
• AES-GCM-SIV si AES imposé.
• AES-GCM avec compteur monotone si état persistant disponible.

8. Padding et ses dangers

8.1 Le problème de padding

Les block ciphers chiffrent par blocs de taille fixe (128 bits AES). Si le plaintext ne fait pas un multiple, il faut le compléter.

PKCS#7 : ajoute N octets valant N à la fin, où N est le nombre d'octets manquants. Si le plaintext fait déjà un multiple, un bloc complet de padding est ajouté.

8.2 Padding oracle attacks

Si l'API révèle que le padding est invalide (via message d'erreur, timing, code de retour), l'attaquant peut déchiffrer byte par byte en forgeant des ciphertexts modifiés.

Exemple CVE Vaudenay 2002, puis BEAST 2011, Lucky 13 2013, POODLE 2014.

Mitigation :

• AEAD (GCM, ChaCha20-Poly1305) élimine le problème : la vérification du tag échoue avant toute interprétation du padding.
• Si CBC inévitable : constant-time MAC check avant padding check.
• Ne jamais différencier l'erreur "padding invalide" de "tag invalide" côté client.

8.3 Stream ciphers - pas de padding

ChaCha20 et CTR ne nécessitent pas de padding : ils chiffrent byte par byte. Un avantage de sécurité.

9. Gestion des clés

9.1 Génération

Utiliser un CSPRNG (voir qu'est-ce que la cryptographie) :

from os import urandom
key = urandom(32)  # 256 bits for AES-256

Ou mieux, délegué à la bibliothèque crypto :

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
key = AESGCM.generate_key(bit_length=256)

9.2 Dérivation de clé - HKDF

Parfois on a une clé principale et on veut en dériver plusieurs clés dédiées (une pour chiffrement, une pour MAC, etc.).

HKDF (HMAC-based Key Derivation Function, RFC 5869) :

from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
 
master_key = ...  # 256 bits
hkdf = HKDF(
    algorithm=hashes.SHA256(),
    length=32,
    salt=b"application salt",
    info=b"encryption key context",
)
derived_key = hkdf.derive(master_key)

Permet de séparer les usages : un leak d'une clé dérivée ne compromet pas les autres.

9.3 Password-based key derivation

Pour dériver une clé à partir d'un mot de passe utilisateur, HKDF n'est pas approprié (trop rapide, bruteforce facile).

Utiliser :

• Argon2id (recommandé).
• scrypt (acceptable).
• PBKDF2 (600 000 iterations minimum pour SHA-256, OWASP 2024).

9.4 Rotation des clés

Les clés doivent tourner périodiquement :

• Rotation planifiée (annuelle ou trimestrielle).
• Rotation sur incident (suspicion de compromission).
• Rotation à la sortie d'un employé qui y avait accès.

Mécanismes :

• Key versioning : chaque objet chiffré indique la version de la clé utilisée.
• Rechiffrement progressif : nouvelles données chiffrées avec nouvelle clé, anciennes déchiffrées avec leur clé historique, migration au fil de l'eau ou batch.

9.5 Envelope encryption

Pattern recommandé cloud :

1. DEK (Data Encryption Key) : clé unique par objet/document.
2. KEK (Key Encryption Key) : clé maître qui chiffre les DEKs.
3. Les DEKs chiffrés sont stockés à côté des données chiffrées.
4. La KEK reste dans le KMS/HSM.

Avantages :

• Rotation de la KEK rapide (re-chiffrer seulement les DEKs, pas les données).
• DEKs courtes vie.
• Audit granulaire par objet.

Implémentations natives : AWS KMS, GCP Cloud KMS, Azure Key Vault, HashiCorp Vault Transit.

10. Pièges d'implémentation

10.1 Nonce réutilisation (le classique)

Déjà vu §7. Le pire péché. Mitigation : abstraction haut niveau, nonce étendu (XChaCha20), GCM-SIV.

10.2 Clé réutilisée entre usages

Utiliser la même clé pour chiffrer des fichiers et signer des tokens et dériver des secrets. Si un usage fuite la clé (via side-channel, bug, backup), tous tombent.

Mitigation : dériver une clé par usage via HKDF ou KMS distincts.

10.3 Timing attacks sur la comparaison de tags

if tag == expected_tag:  # PIEGE
    ...

La comparaison classique de bytes s'arrête au premier mismatch. Timing différent selon la position de la première différence = leak du tag byte par byte.

Mitigation : comparaison constant-time :

import hmac
if hmac.compare_digest(tag, expected_tag):  # constant-time
    ...

Toutes les bibliothèques crypto fournissent cette fonction. Utiliser toujours hmac.compare_digest, crypto.timingSafeEqual, ou équivalent.

10.4 IV / nonce prédictible (CBC BEAST)

Si IV prédictible (par ex. incrémenté), attaque BEAST possible sur CBC. Mitigation : IV aléatoire (CBC) ou préférer AEAD qui gère en interne.

10.5 Authentification à la mauvaise granularité

Chiffrer plusieurs fichiers avec la même clé, stocker les ciphertexts, mais l'attaquant peut échanger deux fichiers ciphertext - l'authentification ne le détecte pas car chaque fichier est individuellement valide.

Mitigation : inclure l'identifiant du fichier/objet dans l'AAD pour lier le ciphertext à son contexte.

10.6 Key leak via logs

logger.info(f"Decrypting with key {key.hex()}")  # CATASTROPHE

Tout log qui inclut une clé cryptographique la persiste à vie dans le SIEM, les backups, les S3 d'export de logs. Mitigation : jamais logger les clés. Tooling de détection pré-commit (gitleaks, trufflehog).

10.7 Persistence des clés en variables d'environnement non protégées

Clé en env var ENCRYPTION_KEY=... visible dans /proc/<pid>/environ, core dumps, crash reports, outputs CI. Mitigation : vault, workload identity, jamais de clé directement en env (ou alors chiffrée elle-même par une clé master dans KMS).

11. Performances

11.1 Benchmarks indicatifs 2026

Sur CPU moderne (x86 avec AES-NI) :

Sur ARM mobile sans AES hardware, ChaCha20 peut doubler AES-GCM.

11.2 Hardware accelerations

• AES-NI (Intel, AMD depuis ~2010) : multiplie par 5-10 la vitesse AES.
• PCLMULQDQ : accélère GHASH (GCM).
• ARMv8 Crypto Extensions : équivalent ARM.
• RISC-V Zkne/Zknd : extensions crypto RISC-V.

Les bibliothèques modernes détectent et utilisent automatiquement ces accélérations.

11.3 Le coût du chiffrement en pratique

Pour une API REST avec TLS terminé en amont (load balancer) :

• Chiffrement de 1 Mo de payload : 0,3-0,5 ms avec AES-GCM.
• Latence réseau typique : 20-100 ms.
• Le chiffrement n'est jamais le goulot.

Pour un batch job qui chiffre 1 To :

• Avec AES-NI : 4-5 minutes.
• Sans AES-NI : 30-60 minutes.

Dimensionnement trivial dans la plupart des cas.

12. Post-quantum - impact sur le symétrique

12.1 L'algorithme de Grover

Un ordinateur quantique exécutant Grover pourrait diviser par 2 la sécurité effective du chiffrement symétrique :

• AES-128 → 64 bits effectifs (insuffisant).
• AES-256 → 128 bits effectifs (acceptable).

12.2 Recommandation

Pour toute donnée devant rester confidentielle au-delà de 2030-2040 (quand des ordinateurs quantiques pertinents pourraient exister) : AES-256 ou ChaCha20-Poly1305 avec clé 256 bits.

Le symétrique ne nécessite pas de nouveaux algorithmes PQ (contrairement à l'asymétrique). Augmenter simplement la taille de clé suffit.

12.3 CNSA 2.0 NSA

Pour systèmes classifiés US :

• AES-256.
• SHA-384 / SHA-512.
• Migration obligatoire d'ici 2035.

13. Bibliothèques recommandées 2026

Critères de choix :

• Maintenue : dernière release moins d'un an.
• CVE historique : propre ou réactive.
• API haut niveau : moins de surface de bug.
• Audit : reviews publiques de la communauté.

14. Checklist chiffrement symétrique

Pour tout code qui chiffre des données :

Choix de primitive

• AEAD obligatoire (AES-GCM, ChaCha20-Poly1305, XChaCha20-Poly1305)
• AES-256 si données long terme
• Jamais ECB, jamais CBC sans MAC

Gestion du nonce

• Nonce unique par message pour cette clé
• Source CSPRNG si aléatoire
• Ou compteur monotone avec état persistant
• XChaCha20 ou GCM-SIV si génération sûre difficile

Gestion de la clé

• CSPRNG pour génération
• Stockage en KMS/HSM/Vault
• Envelope encryption (DEK/KEK)
• Rotation planifiée
• Une clé par usage (HKDF pour dériver)

AAD et contexte

• Inclure le contexte (ID utilisateur, type d'objet, version) dans l'AAD
• Empêche l'échange de ciphertexts entre contextes

Comparaisons

• Toujours constant-time (hmac.compare_digest, crypto.timingSafeEqual)
• Pas de comparaison naïve byte par byte sur tag/MAC

Implémentation

• Bibliothèque mature à jour
• Pas de crypto custom
• Pas de logs contenant les clés
• Pas de secrets en env vars non protégées

Post-quantum readiness

• AES-256 pour données long terme
• ChaCha20 avec clé 256 bits OK
• Pas d'action spécifique avant 2028-2030 pour symétrique

15. Verdict et posture Zeroday

Le chiffrement symétrique est techniquement mature depuis plus de 20 ans. Les deux outils - AES-GCM et ChaCha20-Poly1305 - couvrent 99 % des besoins en production. Ce qui change, ce ne sont pas les algorithmes, ce sont les erreurs d'utilisation : nonce réutilisé, absence d'authentification, comparaison non constant-time, clés mal rotatées.

Pour un développeur : retenir 3 choses. AEAD par défaut (AES-GCM ou ChaCha20-Poly1305). Nonce unique par clé (utiliser une lib qui le gère pour toi quand possible). Pas de crypto custom. Ces trois règles éliminent 90 % des bugs symétriques.

Pour un AppSec : auditer systématiquement la présence de ECB, CBC sans MAC, nonce prédictibles, key reuse entre usages, comparaisons non constant-time. Ces patterns reviennent régulièrement en 2026 dans du code legacy.

Pour une organisation : standardiser sur une bibliothèque haute qualité par langage et interdire les crypto custom en code review produit des gains durables. La centralisation via KMS cloud (AWS/Azure/GCP) pour la gestion des clés élimine 80 % des pièges opérationnels.

Pour approfondir : qu'est-ce que la cryptographie pour le panorama général, JWT : risques et bonnes pratiques pour la crypto appliquée aux tokens, sécurité des workloads cloud pour l'articulation avec KMS cloud, secrets management cloud pour le côté gestion des clés.