Chiffrement / déchiffrement AES

Le chiffrement par blocs. AES (la conception Rijndael, normalisée par le NIST en 2001 sous le nom FIPS 197) chiffre exactement 16 octets à la fois. La longueur de votre clé — 16, 24 ou 32 octets — détermine AES-128, -192 ou -256 et le nombre de tours internes (10, 12 ou 14). Chaque tour mélange le bloc avec des sous-clés dérivées de votre clé, par des tables de substitution, des décalages de lignes et des mélanges de colonnes. Aucune attaque pratique ne casse le chiffrement lui-même : les défaillances réelles viennent presque toujours d’erreurs de mode, d’IV ou de gestion des clés, et c’est le sujet du reste de cette page.

Pourquoi un mode ? Parce que les messages ont rarement 16 octets. Le mode relie les chiffrements de blocs entre eux : ECB chiffre les blocs indépendamment ; CBC applique un XOR de chaque bloc avec le bloc chiffré précédent ; CTR chiffre un compteur et l’applique en XOR avec les données comme un chiffrement à flux ; GCM s’appuie sur CTR et ajoute un tag d’authentification. AES reste le même : le mode change tout quant aux garanties obtenues.

Clés et mots de passe. Une clé AES est faite de 16, 24 ou 32 octets aléatoires. Un mot de passe saisi par une personne ne l’est pas : l’option Mot de passe de cette page dérive une clé correcte avec PBKDF2-HMAC-SHA256 (600 000 itérations par défaut, la référence OWASP 2023 — détails de la dérivation dans le générateur HMAC). N’utilisez jamais une chaîne de mot de passe directement comme clé AES : son entropie ne représente qu’une petite fraction de sa longueur.

Mode	IV / nonce	Intégrité	Remarques
GCM	12 octets, unique par message	Oui — tag de 96 à 128 bits	AEAD : la valeur par défaut recommandée partout (TLS 1.3, SSH, formats de fichiers). Accepte aussi l’AAD.
CBC	16 octets, imprévisible	Non	Bourrage PKCS#7 ; classique, mais nécessite un MAC à côté. Les failles d’oracle de bourrage sont le piège classique de CBC.
CTR	Compteur initial de 16 octets	Non	Pas de bourrage, fonctionnement en flux, accès aléatoire ; réutiliser le nonce sous une même clé révèle le XOR des clairs.
ECB	aucun	Non	Blocs identiques, chiffrés identiques. La démonstration du pingouin ECB. Pour la compatibilité uniquement.

Règles de l’IV en un paragraphe. L’IV n’est pas un secret — envoyez-le avec le chiffré —, mais ses règles d’unicité diffèrent : CBC exige un IV imprévisible ; GCM et CTR exigent seulement de ne jamais réutiliser le même nonce avec la même clé (la réutilisation d’un nonce GCM est pire : elle divulgue la clé d’authentification). Le bouton « IV aléatoire » de cette page utilise le générateur sécurisé du navigateur ; le bouton « Tout à zéro » sert uniquement à reproduire des vecteurs de test, pas à chiffrer de vrais messages.

Bourrage. CBC et ECB exigent des blocs entiers ; le bourrage PKCS#7 ajoute donc de 1 à 16 octets, chacun égal à la longueur du bourrage. C’est pourquoi les chiffrés CBC peuvent grossir jusqu’à 16 octets, et pourquoi un déchiffrement avec la mauvaise clé échoue le plus souvent avec une erreur de bourrage. CTR et GCM fonctionnent comme des chiffrements à flux et n’ont pas besoin de bourrage : la longueur du chiffré est exactement celle du clair (essayez l’exemple en mode CTR : 43 octets en entrée, 43 octets en sortie).

CFB et OFB (les deux autres modes classiques) ne sont pas implémentés sur cette page : ils fonctionnent comme CTR, en flux, mais n’offrent aucun avantage par rapport à lui et survivent surtout dans d’anciens protocoles.

Chiffrement authentifié. GCM = chiffrement CTR + un authentificateur GHASH sur le chiffré, l’IV et l’AAD. Le tag de sortie est une empreinte de l’ensemble : si l’on modifie un seul bit du chiffré, de l’IV ou de l’AAD, le tag ne correspond plus, et le destinataire peut prouver que le message est intact et qu’il provient d’un détenteur de la clé. CBC+HMAC obtient le même résultat seulement si on le compose correctement (chiffrer puis authentifier) — GCM le garantit par construction.

AAD. Les données authentifiées supplémentaires circulent en clair, mais sont couvertes par le tag : en-têtes de protocole, noms de fichiers, identifiants d’algorithme. Le destinataire doit fournir exactement les mêmes octets AAD, sinon la vérification du tag échoue — c’est précisément le but.

Longueur du tag. Le tag par défaut de 128 bits est recommandé ; des tags plus courts (96 à 120 bits) échangent la résistance aux falsifications contre la taille. En dessous de 96 bits, les preuves de sécurité de GCM se dégradent rapidement, c’est pourquoi cette page s’arrête à ce seuil.

La catastrophe du nonce. Réutiliser un nonce GCM de 12 octets sous la même clé révèle le XOR des deux clairs et la sous-clé d’authentification — après quoi des falsifications sont possibles pour tous les messages futurs sous cette clé. Les systèmes qui ne peuvent pas garantir l’unicité utilisent des variantes résistantes à l’usage abusif du nonce (AES-GCM-SIV, RFC 8452).

La première ligne est l’exemple classique à bloc unique de la norme FIPS 197 ; les autres ont été générées par une implémentation native indépendante (OpenSSL via Node.js) et revérifiées sur les moteurs de cette page. Collez la clé, l’IV et l’entrée dans la page pour reproduire chaque ligne.

Cas	Entrées	Sortie attendue
AES-128, bloc unique (style FIPS 197)	key 000102..0f, plaintext 00112233..ff	69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM	key 000102..0f, IV 606162..6b, plaintext 0011..ef ×2	ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, identique mais avec AAD deadbeef	key 000102..1f	ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC	key 000102..1f, IV 101112..1f, plaintext 0011..ef ×2	0e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR (même entrée que CBC ci-dessus)	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

• Utiliser ECB parce qu’il ne nécessite pas d’IV. La facilité est le piège : les motifs des blocs apparaissent directement dans le chiffré (chiffrez une image bitmap et vous verrez encore l’image). ECB n’est acceptable que pour des blocs isolés ou des clés aléatoires de exactement 16 octets — en pratique, à ne jamais choisir délibérément.
• Réutiliser un nonce ou un IV. Avec GCM ou CTR sous une même clé, c’est l’erreur unique qui casse tout d’un coup. Les systèmes à compteur (le bouton « IV aléatoire » de cette page) existent pour la rendre impossible.
• Considérer l’IV comme secret. Ce n’est pas le cas. Stockez-le ou transmettez-le avec le chiffré. Le cacher n’apporte rien et incite à le réutiliser.
• Utiliser un mot de passe directement comme clé. "hunter2hunter2hunter2hunter2" fait 32 octets, mais pas 256 bits d’entropie : c’est un mot du dictionnaire complété. Dérivez la clé avec PBKDF2 (intégré à cette page) ou générez une clé aléatoire.
• Croire que CBC détecte les altérations. Si vous inversez un bit du chiffré CBC, le déchiffrement « réussit » et fournit un clair corrompu sans aucun signal. Seul le tag GCM (ou un HMAC explicite) rend l’altération visible.
• Comparer des chiffrés GCM pour l’égalité. Avec des nonces aléatoires, un même clair est chiffré différemment à chaque fois — c’est voulu. Le chiffrement déterministe est un autre outil, spécialisé.

AES-128 est-il encore sûr, ou faut-il 256 ? Les deux sont sûrs face à des attaquants réalistes ; les meilleures attaques connues réduisent la marge d’une simple fraction. AES-256 compte surtout pour les secrets à long terme et pour la résistance post-quantique (l’algorithme de Grover réduit de moitié la force de la clé, ce qui ramène AES-256 à un équivalent de 128 bits).

Pourquoi openssl enc ne prend-il pas en charge GCM ? La commande enc est antérieure à l’AEAD et ne peut pas transporter de tag ; OpenSSL 3.3 a ajouté pour cela une commande dédiée, aesgcm. La sortie GCM de cette page place le tag sur sa propre ligne, afin que vous puissiez déplacer les deux séparément.

Qu’est-ce que l’enveloppement de clés (AES-KW) ? Un mode spécialisé pour chiffrer d’autres clés par blocs fixes de 64 bits, avec son propre contrôle d’intégrité. Il n’est pas proposé ici, car ses entrées et sorties ont la forme de clés et non de messages : le mauvais usage est la norme.

Pourquoi le chiffré CTR a-t-il la même longueur que le clair, alors que celui de CBC est plus long ? CTR et GCM fonctionnent comme des chiffrements à flux (pas de bourrage) ; CBC et ECB complètent jusqu’à un bloc entier de 16 octets avec PKCS#7. La différence de longueur est voulue, ce n’est pas un bogue.

Puis-je déchiffrer quelque chose chiffré ailleurs ? Oui, si vous connaissez exactement le mode, la clé, l’IV (et, pour GCM, le tag). Les lignes de sortie de cette page consignent tous ces éléments avec précision, pour que vous puissiez transférer les paramètres entre outils ; la zone OpenSSL ci-dessus indique les lignes de commande correspondantes.