Modes d'encryption AES expliqués Pourquoi GCM l'emporte sur CBC dans la plupart des cas (et dans quelles situations ce n'est pas le cas)

Lorsque la documentation vous dit de « utiliser AES-256 », c'est un conseil incomplet. L'AES est un chiffre à bloc — il chiffre exactement un bloc de 128 bits à la fois. Le mode d'opération détermine comment l'AES gère les données réelles plus longues que 16 octets, et combien il vous protège des attaquants qui peuvent observer ou modifier le texte chiffré. Une mauvaise configuration de ce mode est la cause d'une donnée « chiffrée » qui révèle la structure de vos fichiers ou d'un système vulnérable aux attaques de modification de bits.

La spécification complète de l'algorithme ressemble à AES-256-GCM ou AES-128-CBC — taille de clé suivie du mode. Cet article explique ce que fait chaque mode, pourquoi le GCM est le mode par défaut, et dans quelles situations vous pourriez avoir besoin d'un autre mode.

Premièrement, pourquoi ECB est un mythe et non simplement une blague

ECB (Electronic Codebook) est le mode naïf. Chaque bloc de 16 octets de texte clair est chiffré de manière indépendante avec la même clé. Cela signifie que des blocs de texte clair identiques produisent des blocs de texte chiffré identiques.

La démonstration classique est le penguin Linux (Tux) chiffré avec ECB. L'image est chiffrée bloc par bloc, mais comme de grandes zones de l'image sont de couleur uniforme, la version chiffrée montre encore clairement la silhouette d'un penguin. Le chiffrement est mathématiquement valide — les données sont désordonnées — mais la structure est conservée.

Dans la pratique, cela importe chaque fois que votre texte clair contient des répétitions : des lignes de base de données avec un préfixe commun, des en-têtes de fichiers, des champs complétés. ECB révèle la structure. Il n'existe pas de cas légitime d'utilisation de ECB dans le code nouveau. Si vous maintenez du code utilisant ECB : remplacez-le.

Les modes à connaître

CBC — le mode le plus utilisé dans les codes hérités

Le mode de chaînage de blocs XOR chaque bloc de texte clair avec le bloc de texte chiffré précédent avant le chiffrement. Cela élimine le problème de la répétition du mode ECB — des blocs de texte clair identiques produisent des blocs de texte chiffré différents parce que le chaînage fait dépendre le chiffrement de chaque bloc de ce qui a été précédemment chiffré.

CBC nécessite un vecteur d'initialisation (IV) — une valeur aléatoire de 16 octets qui démarre la chaîne pour le premier bloc. L'IV n'a pas besoin d'être secret, mais il doit être aléatoire et doit être transmis avec le texte chiffré.

Le problème avec CBC : il fournit confidentialité mais pas intégrité. Un attaquant qui peut modifier le texte chiffré en transit peut inverser des bits spécifiques dans le résultat déchiffré de manière prédicte. C'est la base des attaques de padding oracle, qui ont déjà compromis des systèmes réels (POODLE, BEAST, Lucky Thirteen). Si vous utilisez CBC sans un code d'authentification séparé (MAC) pour vérifier l'intégrité, vous êtes vulnérable. Le modèle s'appelle « chiffrer puis MAC » — chiffrer d'abord, puis HMAC le texte chiffré, puis vérifier le MAC avant de le déchiffrer. Faire cela dans l'ordre incorrect est une erreur classique.

CBC est également séquentiel — vous ne pouvez pas paralléliser le chiffrement (chaque bloc dépend du bloc précédent chiffré) et le déchiffrement est partiellement parallélisable.

CTR — comportement d'un chiffre de flux provenant d'un chiffre à bloc

Le mode de compteur transforme l'AES en un chiffre de flux. Au lieu de chiffrer directement le texte clair, il chiffre des valeurs de compteur successives et XOR le résultat avec le texte clair. Cela signifie que le mode CTR n'a pas besoin de padding (il fonctionne sur des données de longueur arbitraire), est entièrement parallélisable dans les deux sens, et permet un accès aléatoire à n'importe quelle position du texte chiffré lors du déchiffrement.

CTR utilise un nonce (nombre utilisé une fois) plutôt qu'un IV complet. Le nonce doit être unique par message pour une clé donnée — réutiliser un nonce avec la même clé révèle l'XOR des deux textes clairs, ce qui est catastrophique. Contrairement au CBC, CTR n'a pas de protection d'intégrité. Même histoire : il faut chiffrer-ensuite-MAC si vous voulez une résistance aux modifications.

CTR s'applique lorsque vous avez besoin de propriétés de chiffre de flux — de grands fichiers, déchiffrement avec accès aléatoire, des scénarios à haute performance où la parallélisation est importante — et que vous gérez la couche MAC séparément.

GCM — chiffrement authentifié, une étape

Le mode Galois/Counter (GCM) est le mode CTR avec une étiquette d'authentification intégrée (GHASH). Vous obtenez confidentialité et intégrité dans une seule primitive. L'étiquette d'authentification — généralement de 128 bits — permet au destinataire de vérifier que le texte chiffré n'a pas été modifié avant le déchiffrement. Aucune étape HMAC supplémentaire, aucune chance de faire une erreur d'ordre « chiffrer-ensuite-MAC ».

GCM supporte également Données authentifiées supplémentaires (AAD) — des données qui sont authentifiées mais pas chiffrées. Cela est utile pour les en-têtes, les métadonnées ou tout autre type de données nécessitant une protection d'intégrité mais ne nécessitant pas de confidentialité. L'AAD est vérifiée contre l'étiquette d'authentification, ainsi que le texte chiffré.

Le nonce pour GCM est de 96 bits (12 octets) par défaut. Comme CTR, la réutilisation d'un nonce avec la même clé est fatale — réutiliser un nonce avec la même clé sous GCM révèle à la fois le texte clair et la clé d'authentification (H), ce qui brise complètement la sécurité. Générez toujours des nonces avec un générateur de nombres aléatoires cryptographiquement sécurisés ; ne les dérivez pas à partir de compteurs séquentiels sauf si vous avez un schéma de compteur distribué soigneusement contrôlé.

GCM est parallélisable et n'a pas besoin de padding. C'est la recommandation par défaut dans TLS 1.3, le protocole Signal et la plupart des bibliothèques cryptographiques modernes. Si vous écrivez un nouveau code, GCM est votre choix par défaut.

Comparaison des modes

Mode	Authentifié	Parallélisable	A besoin de padding	Risque de réutilisation du nonce/IV	Verdict
ECB	Non	Oui	Oui	N/A (aucun IV)	Jamais utiliser
CBC	Non (ajouter un MAC)	Chiffrement : Non / Déchiffrement : Oui	Oui	Modéré	Utilisation héritée uniquement
CTR	Non (ajouter un MAC)	Oui	Non	Critique — réutilisation = fuite du texte clair	Utilisation niche
GCM	Oui (intégré)	Oui	Non	Critique — réutilisation = rupture complète	Choix par défaut

AES-256-GCM dans Node.js

Voici une implémentation complète de chiffrement/déchiffrement utilisant le module intégré de Node.js — aucune dépendance requise : crypto Quelques points à noter sur ce code :

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const NONCE_LENGTH = 12; // 96 bits — GCM default
const TAG_LENGTH = 16; // 128-bit auth tag

function encrypt(plaintext, key) {
  const nonce = crypto.randomBytes(NONCE_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });

  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();

  // Prepend nonce + tag to ciphertext for storage/transmission
  return Buffer.concat([nonce, tag, encrypted]);
}

function decrypt(ciphertext, key) {
  const nonce = ciphertext.subarray(0, NONCE_LENGTH);
  const tag = ciphertext.subarray(NONCE_LENGTH, NONCE_LENGTH + TAG_LENGTH);
  const data = ciphertext.subarray(NONCE_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });
  decipher.setAuthTag(tag);

  // Throws if auth tag doesn't match — do not catch this silently
  return Buffer.concat([decipher.update(data), decipher.final()]).toString('utf8');
}

// Generate a key (do this once; store it securely)
const key = crypto.randomBytes(KEY_LENGTH);

const message = 'Hello, authenticated encryption.';
const ciphertext = encrypt(message, key);
console.log('Encrypted:', ciphertext.toString('hex'));

const plaintext = decrypt(ciphertext, key);
console.log('Decrypted:', plaintext); // Hello, authenticated encryption.

Le nonce est généré de manière aléatoire à chaque appel de chiffrement

• est cryptographiquement sécurisé. Ne le remplacez pas par un compteur sauf si vous comprenez le problème de l'unicité distribuée. — crypto.randomBytes Le nonce et l'étiquette d'authentification sont stockés avec le texte chiffré
• — ils doivent accompagner les données chiffrées. Le nonce est public ; l'étiquette est publique. Seule la clé est secrète. — cela lance une erreur en cas d'échec d'authentification
• decipher.final() — ce comportement est correct. Ne le rattrapez pas silencieusement et ne retournez pas un texte partiel. L'échec de l'authentification signifie que les données ont été modifiées ou que la clé est incorrecte. La gestion de la clé est la partie la plus difficile
• vous donne une bonne clé, mais où vous la stockez et la rotate est plus important que le choix de l'algorithme. Utilisez un gestionnaire de secrets, pas une constante codée. — crypto.randomBytes(32) Souhaitez-vous tester les modes de chiffrement de manière interactive ?

IO Tools’ outil de chiffrement/déchiffrement AES vous permet de chiffrer et déchiffrer avec les modes CBC et GCM directement dans le navigateur — utile pour vérifier l'interopérabilité ou déboguer une intégration. Pour générer une clé cryptographiquement sécurisée de 256 bits, utilisez le Générateur de clé AES Vecteur d'initialisation (IV) et nonce : les règles qui comptent vraiment.

L'erreur de gestion du nonce/IV cause plus de ruptures dans le monde réel que le choix de l'algorithme. Les règles :

Générez toujours les nonces/IV avec un générateur de nombres aléatoires cryptographiquement sécurisé

• dans Node, — crypto.randomBytes() dans Java. Pas os.urandom() en Python, SecureRandom . Pas une date. Pas un compteur croissant sauf si c'est un compteur global correctement géré avec des garanties strictes d'unicité. Math.random()La réutilisation du nonce dans GCM provoque une rupture totale de l'authentification
• — avec la même clé et le même nonce, GCM révèle la clé d'authentification H. Un attaquant peut alors créer des étiquettes d'authentification pour des textes chiffrés arbitraires. Ce n'est pas théorique : l'attaque Forbidden exploite cela et a été utilisée contre des implémentations réelles. La réutilisation du IV dans CBC est moins catastrophique mais reste mauvaise
• — les attaques par texte clair choisi deviennent possibles. En pratique, générez toujours un IV frais par message. Ne dérivez jamais un nonce à partir du contenu du message
• — des nonces déterministes dépendant de données prévisibles créent des motifs prévisibles. Utilisez la randomisation. Quand CBC ou CTR reste le bon choix

GCM n'est pas toujours la solution :

Interopérabilité avec des systèmes hérités

• — si vous intégrez avec un système qui ne parle que d'AES-CBC, vous utilisez CBC. Documentez clairement la nécessité d'un MAC et implémentez-le correctement (chiffrer-ensuite-MAC avec HMAC-SHA256). Environnements contraints sans accélération GHASH en matériel
• — l'étape d'authentification de GCM utilise GHASH, qui est plus lourd en termes de calcul que l'opération de chiffrement brut sur un matériel sans accélération dédiée. Certains cibles embarquées où CTR+CMAC est disponible mais GHASH n'est pas disponible peuvent justifier l'utilisation du mode CTR. Chiffrement en flux de très grands fichiers où vous avez besoin de déchiffrement avec accès aléatoire
• — la propriété d'accès aléatoire de CTR est utile lorsque vous devez déchiffrer une position N sans lire les positions 0 à N-1. GCM permet théoriquement cela, mais la vérification de l'étiquette d'authentification nécessite de traiter tout le texte chiffré d'abord, ce qui annule l'avantage. Chiffrement de disque
• — le chiffrement complet de disque utilise le mode XTS (pas couvert ici), pas GCM, car XTS est conçu pour des secteurs de taille fixe et accessibles aléatoirement. GCM est destiné au chiffrement de messages, pas au chiffrement de secteurs. Version courte

AES-256-GCM

Utilisez pour le nouveau code. Générez un nonce aléatoire de 12 octets à chaque appel de chiffrement. Stockez le nonce et l'étiquette d'authentification avec le texte chiffré. Traitez les échecs d'authentification comme des erreurs, pas comme des avertissements — ne retournez jamais un texte partiel lorsque GCM indique que les données sont invalides. Si vous auditiez un code existant utilisant CBC : vérifiez que le modèle « chiffrer-ensuite-MAC » est correctement implémenté, vérifiez que les IV sont aléatoires (pas réutilisés, pas séquentiels), et prévoyez un chemin de migration vers GCM lorsque la fenêtre de maintenance est disponible. Le CBC avec un HMAC correct n'est pas cassé — il a simplement plus de pièges que GCM.

ECB : remplacez-le simplement. Il n'existe pas de chemin d'audit qui se termine par « ECB est acceptable ici. »

AES Encryption Modes Explained: Why GCM Beats CBC in Most Cases (and When It Doesn’t) 2

Vous aimerez peut-être aussi