AES expliqué - Structure, modes, AES-NI, attaques, usages

AES (Advanced Encryption Standard) est l'algorithme de chiffrement symétrique le plus déployé au monde. Il protège TLS (HTTPS), IPsec, WPA2/WPA3 (Wi-Fi), BitLocker (disques Windows), FileVault (macOS), LUKS (Linux), AWS/Azure/GCP KMS (cloud), Signal, iMessage, WhatsApp, et la quasi-totalité des communications chiffrées professionnelles. Publié en 2001 après un concours public international, AES reste mathématiquement solide 25 ans plus tard : aucune attaque pratique, standardisé par le NIST (FIPS 197), recommandé par la NSA (CNSA 2.0). Ce guide explique en détail comment AES fonctionne (structure SPN, 10-14 rounds, 4 opérations, key schedule), pourquoi il est si robuste, comment l'utiliser correctement (modes GCM/CCM/XTS), et ce qui le rend différent de ses alternatives.

1. Origine et contexte historique

1.1 Avant AES - l'ère DES

DES (Data Encryption Standard), adopté par le NIST en 1977, était la référence pendant 25 ans. Mais :

• Clé 56 bits → cassable par bruteforce dès 1998 (EFF DES Cracker, machine dédiée).
• 3DES (triple DES) prolonge la vie jusqu'aux années 2010, mais lent.
• En 1997, le NIST lance un concours international pour un successeur.

1.2 Le concours AES (1997-2001)

15 candidats soumis, réduits à 5 finalistes :

• MARS (IBM).
• RC6 (RSA Laboratories).
• Rijndael (Joan Daemen et Vincent Rijmen, cryptographes belges).
• Serpent (Anderson, Biham, Knudsen).
• Twofish (Schneier et al.).

Critères d'évaluation : sécurité, performance logicielle, performance hardware, simplicité, flexibilité, licence.

Rijndael sélectionné en octobre 2000, standardisé en 2001 (FIPS 197). Choix : rapidité universelle, structure propre, pas de brevets, flexibilité (tailles multiples).

1.3 Pourquoi ce choix a tenu 25 ans

• Structure mathématiquement élégante.
• Communauté de recherche mondiale qui a tenté de l'attaquer pendant 25 ans : aucune attaque pratique trouvée.
• Intégration hardware : Intel AES-NI dès 2010, devenu universel. Accélération x10.
• Adoption massive : standard TLS, IPsec, WPA2+, cloud providers. Effet de réseau difficile à inverser.

2. Paramètres AES

2.1 Tailles

• Taille de bloc fixe : 128 bits (16 octets). Pas de variation.
• Tailles de clé : 128, 192, ou 256 bits (16, 24, ou 32 octets).

Trois variantes couramment nommées :

• AES-128 : clé 128 bits, 10 rounds.
• AES-192 : clé 192 bits, 12 rounds.
• AES-256 : clé 256 bits, 14 rounds.

2.2 Tableau récapitulatif

La sécurité nominale signifie : bruteforce exhaustif demande 2^n opérations. Pour 2^128, infaisable avec les ressources mondiales cumulées pour des milliards d'années.

2.3 Pourquoi trois tailles

• AES-128 : cible la sécurité suffisante pour la plupart des usages avec performance maximale.
• AES-192 : compromis intermédiaire, rarement utilisé en pratique.
• AES-256 : pour données à très longue durée de vie, environnements hautement sensibles, résistance pré-quantum.

AES-192 est pratiquement absent de la plupart des implémentations. Les choix réels se font entre AES-128 et AES-256.

3. Structure - SPN (Substitution-Permutation Network)

3.1 Principe général

AES est un block cipher qui applique une série de rounds (10, 12 ou 14) sur un bloc de 128 bits. Chaque round est une séquence de 4 opérations :

1. SubBytes : substitution non-linéaire.
2. ShiftRows : permutation.
3. MixColumns : diffusion.
4. AddRoundKey : XOR avec une clé dérivée.

La combinaison non-linéaire (SubBytes) + linéaire (ShiftRows + MixColumns) crée la structure SPN qui est prouvablement résistante à la cryptanalyse différentielle et linéaire.

3.2 État - la matrice 4x4

Le bloc de 128 bits est organisé comme une matrice 4x4 d'octets (le "state") :

| b0  b4  b8   b12 |
| b1  b5  b9   b13 |
| b2  b6  b10  b14 |
| b3  b7  b11  b15 |

Toutes les opérations d'un round modifient cet état.

3.3 Vue d'ensemble d'un round complet

Pour AES-128 (10 rounds) :

PlainText (128 bits)
  └── AddRoundKey(K0)
  ├── Round 1  : SubBytes → ShiftRows → MixColumns → AddRoundKey(K1)
  ├── Round 2  : SubBytes → ShiftRows → MixColumns → AddRoundKey(K2)
  ├── ...
  ├── Round 9  : SubBytes → ShiftRows → MixColumns → AddRoundKey(K9)
  └── Round 10 : SubBytes → ShiftRows → AddRoundKey(K10)   [pas de MixColumns]
                                                             │
                                                             ▼
                                                        CipherText

Le dernier round omet MixColumns pour des raisons de structure symétrique (facilite le déchiffrement).

Le déchiffrement applique les opérations inverses dans l'ordre inverse.

4. Les 4 opérations par round

4.1 SubBytes - substitution non-linéaire

Chaque octet du state est remplacé par un autre octet selon une table fixe appelée S-box (256 entrées).

La S-box est construite mathématiquement comme :

• Inverse multiplicatif dans le corps de Galois GF(2^8).
• Suivi d'une transformation affine.

Propriétés :

• Non-linéaire : empêche les attaques algébriques.
• Maximise la propriété avalanche : un bit changé en entrée = environ la moitié des bits changés en sortie.
• Constant-time en principe, mais attention aux implémentations table-based (voir §11).

4.2 ShiftRows - permutation

Les lignes du state sont décalées cycliquement :

• Ligne 0 : pas de décalage.
• Ligne 1 : décalée de 1 position à gauche.
• Ligne 2 : décalée de 2 positions à gauche.
• Ligne 3 : décalée de 3 positions à gauche.

Effet : diffuse l'information entre les colonnes de la matrice.

4.3 MixColumns - diffusion

Chaque colonne du state est multipliée par une matrice fixe sur GF(2^8) :

| 2  3  1  1 |   | s0 |
| 1  2  3  1 | × | s1 |
| 1  1  2  3 |   | s2 |
| 3  1  1  2 |   | s3 |

Effet : chaque octet d'entrée affecte tous les octets de sortie de la colonne. Diffuse localement.

MixColumns est omis au dernier round (nécessité mathématique pour la symétrie du déchiffrement).

4.4 AddRoundKey - XOR avec clé dérivée

Le state est XORé avec une round key de 128 bits dérivée de la clé maître via le key schedule (§5).

C'est la seule opération qui fait entrer la clé dans le calcul. Chaque round utilise une clé différente.

4.5 Combinaison des effets

• SubBytes apporte la non-linéarité (confusion).
• ShiftRows + MixColumns apportent la diffusion.
• AddRoundKey mélange avec le secret.

Après 3-4 rounds, chaque bit de sortie dépend de tous les bits d'entrée ET de la clé. Les 10-14 rounds fournissent une marge confortable contre les attaques connues.

5. Key Expansion (Key Schedule)

5.1 Objectif

La clé maître (128/192/256 bits) est expandée en plusieurs round keys de 128 bits chacune :

• AES-128 : 11 round keys (K0 à K10).
• AES-192 : 13 round keys (K0 à K12).
• AES-256 : 15 round keys (K0 à K14).

Chaque round utilise une round key différente.

5.2 Fonctionnement

La key expansion applique itérativement :

• RotWord : rotation cyclique d'un mot de 4 octets.
• SubWord : application de la S-box à chaque octet.
• XOR avec Rcon : tableau de constantes pré-calculées.

Le résultat : une séquence de mots de 32 bits, groupés en round keys.

5.3 Pourquoi c'est important

Le key schedule assure que chaque round key est distincte et fonction complexe de la clé maître. Une attaque sur un round ne permet pas trivialement de récupérer la clé maître.

Historiquement, certaines variantes de key schedule ont été sources d'attaques (ex. related-key attacks sur AES-192/256 → attaque bicorn académique, pas pratique).

6. Pourquoi AES est si robuste

6.1 Fondations mathématiques

AES repose sur des constructions mathématiquement prouvées :

• SPN résiste prouvablement à la cryptanalyse différentielle et linéaire (publiés par Biham-Shamir 1990, Matsui 1993).
• S-box construite pour maximiser la propriété avalanche et la non-linéarité.
• MixColumns sur GF(2^8) assure une diffusion optimale.

6.2 25 ans de cryptanalyse publique

Depuis 2001, la communauté crypto mondiale attaque AES :

• Cryptanalyse différentielle : inefficace.
• Cryptanalyse linéaire : inefficace.
• Attaques algébriques : pas de percée.
• Related-key attacks : marginales, théoriques seulement.
• Biclique cryptanalysis (Bogdanov, Khovratovich, Rechberger 2011) : meilleure attaque publique sur full AES.

Meilleures attaques actuelles :

• AES-128 : 2^126 opérations (biclique). Gain de 2 bits sur bruteforce. Reste infaisable.
• AES-256 : 2^254 opérations (biclique). Gain de 2 bits.

Aucune attaque n'affaiblit AES au point de le rendre cassable.

6.3 Marge de sécurité des rounds

Les versions réduites (AES à 6-7 rounds) sont cassables. Mais AES-128 utilise 10 rounds, AES-256 utilise 14. La marge est large.

7. AES-NI - l'accélération hardware

7.1 Les instructions AES-NI

AES-NI (AES New Instructions) est un jeu d'instructions CPU qui accélère massivement AES. Introduit par Intel en 2010 (Westmere), puis par AMD, ARM, et plus récemment RISC-V.

Instructions principales :

• AESENC : un round de chiffrement AES.
• AESENCLAST : dernier round de chiffrement.
• AESDEC / AESDECLAST : équivalents pour déchiffrement.
• AESKEYGENASSIST : aide au key schedule.
• PCLMULQDQ : multiplication carry-less (accélère GCM).

7.2 Gain de performance

Avec AES-NI :

• AES-128-GCM : 3 à 5 Go/s sur un core moderne (vs ~300 Mo/s sans AES-NI).
• Latence par bloc : quelques nanosecondes.
• Le chiffrement devient quasi gratuit en terme de CPU.

7.3 Support multi-plateforme

• Intel : AES-NI depuis Westmere (2010), universel en 2026.
• AMD : depuis Bulldozer (2011).
• ARM : ARMv8 Crypto Extensions (ARMv8-A +crypto), Apple M-series, Qualcomm Snapdragon.
• RISC-V : extensions Zkne/Zknd récentes.
• GPU : implémentations CUDA, moins répandues.

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

7.4 Impact sur les bonnes pratiques

Avec AES-NI, la performance n'est plus un critère pour choisir entre AES-128 et AES-256. L'écart de rounds (10 vs 14) est négligeable face à la latence réseau.

Recommandation pratique : si AES-NI disponible (99 % des serveurs modernes), utiliser AES-256-GCM sans se soucier du coût.

8. Attaques connues sur AES

8.1 Attaques mathématiques

Comme vu §6.2, les attaques mathématiques sur AES full-round restent théoriques :

• Biclique : gain de 2 bits sur bruteforce, impraticable.
• Related-key : marginal sur AES-256, inexploitable en pratique.
• Algebraic attacks : pas de percée.

AES reste imbattu cryptanalytiquement.

8.2 Attaques d'implémentation - side-channels

Les implémentations peuvent fuiter des informations même si l'algorithme est parfait. Attaques :

• Cache-timing attacks (Bernstein 2005, Osvik-Shamir-Tromer 2006) : une implémentation table-based de la S-box permet d'observer les accès cache → bruteforce de la clé.
• Power analysis : mesure de la consommation électrique pendant le chiffrement.
• Electromagnetic emanation : mesure des ondes EM.
• Acoustic cryptanalysis : bruit du CPU (marginal).

8.3 Mitigations

• Constant-time implementations : éviter les branchements dépendants de la clé, éviter les accès table dépendants de la clé.
• AES-NI : les instructions hardware sont immunisées aux cache-timing.
• Bitslicing : technique software constant-time (BearSSL, NaCl).
• Isolation hardware : TEE (Intel SGX, ARM TrustZone, AMD SEV).
• Masking : randomiser les calculs intermédiaires.

8.4 Attaques contextuelles (pas sur AES mais utilisant AES)

• Nonce réutilisation en GCM : casse complètement GCM (permet de récupérer la clé d'authentification). Pas une attaque sur AES mais sur son mode.
• Padding oracle en CBC : BEAST, Lucky 13, POODLE. Encore une fois, problème du mode et de l'usage, pas d'AES.

Voir chiffrement symétrique expliqué pour les détails sur les modes.

9. AES-128 vs AES-256 - choix en pratique

9.1 Sécurité effective

• AES-128 : 128 bits de sécurité nominale. Bruteforce infaisable avec les ressources actuelles (environ 2^128 opérations, au-delà des capacités cumulées de toute l'informatique mondiale pendant des milliards d'années).
• AES-256 : 256 bits nominaux. Marge de sécurité énorme.

9.2 Pourquoi choisir AES-256

Raisons valides :

• Résistance post-quantum : Grover divise la sécurité par 2 → AES-128 devient 64 bits effectifs (insuffisant), AES-256 devient 128 bits (acceptable).
• Données à très longue durée de vie : si tu chiffres aujourd'hui des données qui doivent rester secrètes 30 ans, hedge avec AES-256.
• Conformité : CNSA 2.0 (NSA), certaines réglementations imposent AES-256.
• Consistance : si tu veux une seule configuration pour tous les usages.

Raisons invalides mais parfois entendues :

• "256 est plus sûr donc mieux" : 128 bits sont déjà infaisables. Ajouter des bits est un hedge, pas une amélioration pratique.
• "La performance est similaire" : vrai avec AES-NI, mais ce n'est pas un argument positif pour 256.

9.3 Pourquoi AES-128 reste valide

• Plus rapide (10 rounds vs 14, 40 % plus rapide théoriquement).
• Plus simple à raisonner sur la sécurité (attaques related-key sur AES-256 n'existent pas sur AES-128).
• Standard TLS : AES-128-GCM est le cipher suite par défaut de TLS 1.3.

9.4 Recommandation pratique 2026

• Pour nouveaux projets avec hedge long terme : AES-256-GCM.
• Pour compat TLS par défaut : AES-128-GCM est OK.
• Les deux sont sûrs, la décision finale n'est pas critique dans la plupart des cas.

10. Modes d'opération AES

10.1 Rappel - AES seul est un block cipher

AES chiffre un bloc de 128 bits. Pour chiffrer un message plus long, il faut un mode d'opération qui combine plusieurs blocs. Voir chiffrement symétrique expliqué pour le panorama complet.

10.2 Modes AEAD recommandés

AES-GCM (Galois/Counter Mode) :

• AEAD (authentification intégrée).
• Parallélisable, rapide avec AES-NI + PCLMULQDQ.
• Standard TLS 1.3, IPsec, SSH, 802.1AE.
• Nonce 96 bits critique : jamais réutiliser avec la même clé.

AES-GCM-SIV (RFC 8452) :

• Variant de GCM résistant à la réutilisation de nonce.
• Légèrement plus lent mais plus robuste.
• Recommandé quand la garantie d'unicité du nonce est difficile.

AES-CCM :

• AEAD, utilisé dans WPA2/WPA3, TLS, Bluetooth.
• Plus lourd que GCM, moins utilisé en général mais standard dans certains protocoles IoT.

AES-OCB3 :

• AEAD excellent, anciennement limité par brevets (expirés).
• Peu adopté par effet de réseau.

10.3 AES-XTS - chiffrement de disques

Mode conçu pour le chiffrement de stockage :

• Chaque bloc chiffré différemment selon sa position (tweak).
• Pas d'authentification (trade-off pour la performance et l'espace).
• Utilisé par : BitLocker, FileVault, LUKS/dm-crypt, AWS EBS encryption, Google Cloud disk encryption.

Ne pas utiliser AES-XTS pour communication : pas d'authentification, susceptibilité aux attaques actives.

10.4 Modes à éviter

• AES-ECB : danger, patterns visibles (cf. pingouin chiffré).
• AES-CBC sans MAC : padding oracle attacks.
• AES-CTR sans MAC : malléabilité.

Si tu vois l'un de ces modes dans du code, c'est un bug à corriger.

11. Implémentations à utiliser

11.1 Critères de choix

• Maintenue activement.
• Auditée.
• Supporte AES-NI et les accélérations hardware.
• Expose des API AEAD haut niveau (pas juste AES-ECB/CBC).
• Gère les modes modernes (GCM, GCM-SIV).

11.2 Bibliothèques recommandées par langage

11.3 Exemple Python - AES-256-GCM

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
 
# Générer la clé
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)
 
# Chiffrer
nonce = os.urandom(12)  # 96 bits, unique par message
plaintext = b"donnees sensibles"
aad = b"context: user_id=12345"
ciphertext = aesgcm.encrypt(nonce, plaintext, aad)
 
# Déchiffrer
plaintext_recovered = aesgcm.decrypt(nonce, ciphertext, aad)

11.4 Exemple Node.js - AES-256-GCM

const crypto = require('crypto');
 
const key = crypto.randomBytes(32);  // 256 bits
const nonce = crypto.randomBytes(12);
const aad = Buffer.from('context: user_id=12345');
 
// Chiffrer
const cipher = crypto.createCipheriv('aes-256-gcm', key, nonce);
cipher.setAAD(aad);
const encrypted = Buffer.concat([cipher.update('donnees sensibles'), cipher.final()]);
const authTag = cipher.getAuthTag();
 
// Déchiffrer
const decipher = crypto.createDecipheriv('aes-256-gcm', key, nonce);
decipher.setAAD(aad);
decipher.setAuthTag(authTag);
const decrypted = Buffer.concat([decipher.update(encrypted), decipher.final()]);

11.5 Exemple Go - AES-256-GCM

package main
 
import (
    "crypto/aes"
    "crypto/cipher"
    "crypto/rand"
)
 
func main() {
    key := make([]byte, 32)
    rand.Read(key)
 
    block, _ := aes.NewCipher(key)
    aesgcm, _ := cipher.NewGCM(block)
 
    nonce := make([]byte, aesgcm.NonceSize())
    rand.Read(nonce)
 
    aad := []byte("context: user_id=12345")
    plaintext := []byte("donnees sensibles")
 
    ciphertext := aesgcm.Seal(nil, nonce, plaintext, aad)
 
    // Déchiffrer
    plaintextRecovered, _ := aesgcm.Open(nil, nonce, ciphertext, aad)
    _ = plaintextRecovered
}

12. Erreurs classiques d'implémentation

12.1 Utiliser AES-ECB

# CATASTROPHE
cipher = Cipher(algorithms.AES(key), modes.ECB())

Patterns visibles, jamais accepté en prod. Si tu vois ça, remplace par AES-GCM.

12.2 Utiliser AES-CBC sans MAC

# MAUVAIS
cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
# Vulnérable aux padding oracle attacks

Mitigation : encrypt-then-MAC avec HMAC-SHA-256, ou mieux, passer à AES-GCM.

12.3 Nonce réutilisé en GCM

# CATASTROPHE silencieuse
nonce = b"\x00" * 12  # Même nonce pour chaque message = clé compromise
aesgcm.encrypt(nonce, msg1, None)
aesgcm.encrypt(nonce, msg2, None)

Mitigation : os.urandom(12) à chaque message, ou compteur monotone strict.

12.4 Key reuse entre usages

Utiliser la même clé AES pour chiffrer des fichiers, signer des tokens, et encrypt des cookies. Mitigation : dériver une clé par usage via HKDF.

12.5 Clé courte (AES-128 avec clé < 128 bits d'entropie)

Générer la clé via hash("mypassword") → entropie réelle = entropie du password, potentiellement quelques bits.

Mitigation : os.urandom(32) pour génération, ou Argon2id si dérivation depuis password.

12.6 Implémentation non constant-time

Utiliser une implémentation AES table-based (S-box en RAM) sur CPU sans AES-NI = vulnérable aux cache-timing.

Mitigation : bibliothèque moderne qui choisit automatiquement entre AES-NI et bitslicing.

12.7 Oublier d'authentifier l'AAD

Chiffrer avec GCM mais oublier de passer un AAD approprié. Les messages peuvent être échangés entre contextes.

Mitigation : inclure tous les metadata pertinents dans l'AAD (user_id, timestamp, type d'objet).

12.8 Variable IV reuse en CBC

# IV fixe ou prédictible en CBC
iv = b"my_fixed_iv_012"

IV prédictible en CBC = BEAST attack possible (TLS 1.0). Mitigation : IV aléatoire unique par message, ou passer à GCM.

13. AES dans les protocoles réels

13.1 TLS 1.3

Cipher suites avec AES :

• TLS_AES_128_GCM_SHA256 : AES-128-GCM + SHA-256. Standard.
• TLS_AES_256_GCM_SHA384 : AES-256-GCM + SHA-384. Hauts niveaux.
• TLS_CHACHA20_POLY1305_SHA256 : alternative ChaCha20.

TLS 1.3 interdit les modes faibles (CBC sans AEAD, RC4, 3DES).

13.2 IPsec

IKEv2 supporte AES-GCM, AES-CCM, AES-CBC (legacy). Standard moderne : AES-GCM.

13.3 WPA3

WPA3 impose AES-256 en mode CCMP ou GCMP pour Wi-Fi Enterprise. WPA2 utilise AES-128-CCMP.

13.4 Disk encryption

• BitLocker : AES-128 ou AES-256 en XTS.
• FileVault : AES-256 en XTS.
• LUKS/dm-crypt : AES-256 en XTS par défaut.
• AWS EBS : AES-256-XTS.
• Azure Disk Encryption : AES-256-XTS.
• Google Cloud PD encryption : AES-256-XTS.

13.5 Messaging sécurisé

• Signal : AES-256 CTR + HMAC-SHA-256 (ou ChaCha20-Poly1305).
• WhatsApp : AES-256 en GCM.
• iMessage : AES-CTR avec ECDSA signing.

13.6 KMS cloud

Tous les KMS cloud (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault Transit) utilisent AES-256-GCM en interne pour envelope encryption.

14. AES et post-quantum

14.1 Grover's algorithm

Un ordinateur quantique exécutant Grover chercherait une clé AES en 2^(n/2) opérations au lieu de 2^n :

• AES-128 → 2^64 opérations effectives. Insuffisant si un ordinateur quantique suffisant existe.
• AES-256 → 2^128 opérations effectives. Acceptable.

14.2 Quand s'inquiéter

Estimations 2024 :

• Ordinateur quantique capable d'attaquer AES-128 : au plus tôt 2035-2040, avec forte incertitude.
• AES-256 : probablement pas cassé par Grover durant ce siècle.

14.3 Recommandation 2026

Pour données à longue durée de vie (plus de 10-15 ans) : AES-256 par précaution.

Pour données court/moyen terme : AES-128 reste parfaitement acceptable.

14.4 CNSA 2.0

La NSA (CNSA 2.0, 2022) impose pour systèmes classifiés US :

• AES-256 en GCM.
• SHA-384/512.
• Transition complète d'ici 2035.

L'ANSSI française suit une trajectoire similaire.

15. AES vs alternatives

15.1 AES vs ChaCha20

Les deux sont excellents. Choix selon plateforme et écosystème.

15.2 AES vs Twofish, Serpent

Autres finalistes du concours AES :

• Twofish : compétitif, peu utilisé en pratique (perte de concours commerciale).
• Serpent : plus conservateur (32 rounds, plus sûr théoriquement), mais lent. Utilisé rarement.

Ces alternatives sont sûres mais marginalisées par l'effet de réseau AES. Pas de raison pratique de préférer à AES.

15.3 AES vs Camellia, ARIA

• Camellia : développé par NTT/Mitsubishi. Utilisé par quelques gouvernements et TLS optionnel. Sûr, peu adopté.
• ARIA : standard coréen. Usage limité à Corée.

16. Checklist AES

Choix de primitive

• AES-GCM par défaut pour AEAD
• AES-GCM-SIV si nonce misuse possible
• AES-CCM pour IoT / Bluetooth
• AES-XTS pour disques seulement
• Jamais ECB, jamais CBC sans MAC

Taille de clé

• AES-256 pour nouveaux projets avec hedge long terme
• AES-128 acceptable pour TLS et court/moyen terme
• Jamais de taille customisée, toujours 128/192/256 exactement

Génération et gestion des clés

• CSPRNG pour génération (os.urandom, crypto.randomBytes)
• KMS ou HSM pour stockage en production
• Envelope encryption (DEK/KEK) pour volumes importants
• Rotation planifiée annuelle ou plus fréquente

Nonce

• 96 bits pour GCM, unique par clé
• Source CSPRNG ou compteur monotone
• Jamais réutilisé (AES-GCM-SIV si risque)

AAD

• Inclure le contexte (IDs, timestamps, versions)
• Empêche l'échange de ciphertexts entre contextes

Implémentation

• Bibliothèque mature (cryptography, crypto/aes, javax.crypto, ring, libsodium)
• AES-NI ou équivalent activé (automatique sur CPU moderne)
• Comparaison constant-time pour tags

Post-quantum

• AES-256 pour données long terme
• Crypto agility dans le design

17. Verdict et posture Zeroday

AES est le standard de facto du chiffrement symétrique en 2026 et le restera probablement pour 10-20 ans. Sa combinaison de sécurité prouvée, performance hardware universelle, adoption massive, standardisation claire et écosystème d'implémentations matures le rend quasi imbattable pour les usages pratiques.

Pour un développeur : utiliser AES-256-GCM (ou ChaCha20-Poly1305 selon plateforme) via une bibliothèque moderne, gérer le nonce correctement, inclure le contexte dans l'AAD. Ces trois points couvrent 95 % des cas d'usage. Pas besoin de comprendre les S-box en détail pour bien utiliser AES.

Pour un AppSec : le check standard dans un audit crypto - "utilisation d'AES-GCM ou équivalent AEAD, nonce unique, AAD approprié, clé via KMS, taille 128 ou 256" - suffit dans la majorité des cas. Les bugs AES en 2026 ne viennent jamais de l'algorithme mais de son mode, de son nonce, ou de sa clé.

Pour une organisation : standardiser sur AES-256-GCM, intégrer la génération et la rotation des clés dans un KMS cloud, et interdire les modes faibles en code review. Ces trois décisions éliminent la majorité des risques AES opérationnels.

Pour approfondir : chiffrement symétrique expliqué pour le panorama des modes, qu'est-ce que la cryptographie pour le contexte général, différence hash/HMAC/signature pour l'articulation avec les MACs (GCM utilise un MAC interne), secrets management cloud pour la gestion des clés AES en production.