Chiffreur/Déchiffreur AES

AES (Advanced Encryption Standard) est l'algorithme de chiffrement symétrique le plus utilisé au monde, approuvé par la NSA pour la protection d'informations TOP SECRET. AES a été développé à partir du chiffre Rijndael conçu par les cryptographes belges Joan Daemen et Vincent Rijmen, et publié officiellement par le NIST en 2001 comme remplacement du DES vieillissant. AES utilise le chiffrement par blocs avec une taille fixe de 128 bits (16 octets) et supporte trois longueurs de clé: 128, 192 et 256 bits. Des clés plus longues offrent une sécurité plus élevée mais une vitesse légèrement inférieure. En tant qu'algorithme symétrique, AES utilise la même clé pour chiffrer et déchiffrer. AES a de nombreuses applications: TLS/SSL pour le web et l'e-mail, BitLocker/FileVault pour le chiffrement de disque, chiffrement de bases de données et sécurité IoT. Cet outil supporte les 6 modes AES (ECB, CBC, CFB, OFB, CTR, GCM) et 5 schémas de remplissage.

AES (Advanced Encryption Standard) a été publié par le NIST sous le nom FIPS 197 en novembre 2001, après une compétition publique de cinq ans lancée en 1997 avec 15 candidats. Le vainqueur fut Rijndael, conçu par les cryptographes belges Joan Daemen et Vincent Rijmen, devançant les finalistes Twofish, Serpent, RC6 et Mars. AES a remplacé le DES (FIPS 46, retiré en 2005) et est désormais le chiffrement symétrique par blocs le plus déployé au monde : il est intégré dans TLS 1.2/1.3, IPsec, BitLocker, FileVault, le mode par défaut d'OpenSSL `aes-256-gcm`, dm-crypt du noyau Linux, CryptoKit d'Apple et Keystore d'Android. La NSA a approuvé AES-256 pour le niveau TOP SECRET en 2003 (suite A), faisant d'AES le premier chiffrement publiquement disponible autorisé pour le plus haut niveau de classification américain. La taille de bloc est fixée à 128 bits (16 octets) ; les tailles de clé sont 128, 192 ou 256 bits, correspondant respectivement à 10, 12 ou 14 rounds. Un round (sauf le dernier) exécute quatre opérations sur un état de 4x4 octets : SubBytes applique une S-Box fixe de 16x16 (0x63 = 01100011 se trouve à la ligne 6 colonne 3 — la S-Box est construite comme l'inverse multiplicatif dans GF(2^8) plus une transformation affine pour briser la structure algébrique) ; ShiftRows décale la ligne 0 de 0, la ligne 1 de 1, la ligne 2 de 2 et la ligne 3 de 3 octets ; MixColumns multiplie chaque colonne par une matrice MDS circulante fixe sur GF(2^8) (le polynôme 0x03 * x sous forme matricielle) ; AddRoundKey applique un XOR avec la sous-clé du round. Le dernier round saute MixColumns. Les clés de round proviennent du calendrier de clés Rijndael : 11/13/15 clés de round de 128 bits chacune, générées via RotWord (rotation gauche d'1 octet), SubWord (application de la S-Box) et XOR avec Rcon[i] = [0x01, 0x02, 0x04, ..., 0x80, 0x1b, 0x36] *2^(i-1) sur GF(2^8). La bibliothèque `aes-js` de la page effectue les quatre étapes en JavaScript pur et est compatible au niveau des octets avec la libcrypto d'OpenSSL. Cinq modes de bloc sont exposés. ECB chiffre chaque bloc de 16 octets indépendamment : des blocs de texte clair identiques produisent des blocs chiffrés identiques, révélant la structure (la fameuse image du pingouin ECB survit au chiffrement car le motif de pixels est préservé). CBC effectue un XOR entre chaque bloc de texte clair et le bloc chiffré précédent avant chiffrement ; le premier bloc est XORé avec un IV. CTR transforme AES en chiffrement par flot en chiffrant un compteur incrémenté (nonce || compteur, les deux moitiés de 64 bits d'un bloc de 128 bits) et en XORant le flux de clé avec le texte clair — il supporte l'accès aléatoire et le chiffrement parallèle. GCM est CTR plus GHASH (un authentificateur à hachage universel sur GF(2^128)), produisant un tag d'authentification de 16 octets ajouté après le texte chiffré. GCM est le mode AEAD par défaut dans TLS 1.3 (RFC 8446) et dans la plupart des API modernes (Node `crypto.createCipheriv('aes-256-gcm', ...)`). CFB et OFB sont des modes de chiffrement par flot plus anciens conservés pour la compatibilité. Le piège de l'IV est le bug de production le plus courant. GCM avec un IV de 96 bits (12 octets) est la configuration recommandée par le NIST (RFC 5288, NIST SP 800-38D §5.2.1.1) : l'IV de 12 octets est traité comme un compteur et GHASH est calculé sur J0 = IV || 0x00000001. La réutilisation d'un IV sous la même clé en mode CTR fuite le XOR des textes clairs (C1 XOR C2 = P1 XOR P2 — une seule attaque à texte clair choisi permet de récupérer les deux messages). La réutilisation d'un IV en GCM est pire : un attaquant peut récupérer la sous-clé d'authentification H et forger des tags pour des messages arbitraires (l'attaque décrite par Joux en 2006 est la raison pour laquelle le NIST a interdit les IV aléatoires de 96 bits sans stricte unicité). La page génère des IV de 12 octets avec `crypto.getRandomValues(new Uint8Array(12))` pour GCM et des IV de 16 octets pour CBC/CFB/OFB, et le bouton de clé aléatoire utilise le même CSPRNG afin que chaque chiffrement débute avec du matériel frais. Cet outil exécute le chiffrement et le déchiffrement AES entièrement dans le navigateur via aes-js (implémentation AES en JavaScript pur). Il n'y a pas de bascule vers Web Crypto / SubtleCrypto : toutes les opérations passent par aes-js quelle que soit la taille des données.

• AES est le FIPS 197 (2001), sélectionné lors d'une compétition ouverte du NIST ayant attiré 15 candidats ; Rijndael a battu Twofish, Serpent, RC6 et Mars. La taille de bloc est toujours de 128 bits ; les tailles de clé 128/192/256 bits exécutent 10/12/14 rounds. La page prend en charge les trois via les constructeurs AES_128, AES_192 et AES_256 de aes-js.
• La fonction de round en quatre étapes : SubBytes (une S-Box de 256 octets qui est l'inverse dans GF(2^8) plus une transformation affine), ShiftRows (lignes décalées de 0/1/2/3 octets), MixColumns (multiplication matricielle MDS sur GF(2^8) avec le polynôme 0x03), AddRoundKey (XOR avec la clé de round). Le dernier round saute MixColumns. Même algorithme, même clé = même chiffré — AES est déterministe.
• ECB n'est pas sûr car des blocs de texte clair identiques produisent des blocs chiffrés identiques (la fameuse image du « pingouin ECB » conserve sa silhouette). CBC est le mode classique sûr ; CTR ajoute le parallélisme ; GCM ajoute l'authentification et est le mode par défaut de TLS 1.3 (RFC 8446). CFB et OFB sont des modes de chiffrement par flot conservés pour la compatibilité avec les anciens systèmes.
• Remplissage PKCS#7 : 1 octet manquant → 15 octets de 0x0f + 1 octet de 0x10 ; 2 octets manquants → 14 de 0x0e + 2 de 0x0f, etc. La valeur du dernier octet indique la longueur du remplissage, donc le retrait est sans ambiguïté. Les modes par flot (CTR/CFB/OFB/GCM) sautent entièrement le remplissage. ZeroPadding est ambigu lorsque les données se terminent par 0x00 — ne l'utilisez pas.
• GCM est un mode AEAD : texte chiffré plus un tag d'authentification de 16 octets, calculé via GHASH sur GF(2^128) en utilisant H = AES_K(0^128). Les AAD (données additionnelles authentifiées) couvrent les en-têtes sans les chiffrer. L'IV de 96 bits (RFC 5288) est traité comme un compteur ; les IV de 128 bits passent par un GHASH pour dériver J0 — même sécurité, légèrement plus lent.
• La réutilisation d'un IV est catastrophique. La réutilisation d'un IV en CTR fuite P1 XOR P2 (double utilisation du masque). La réutilisation d'un IV en GCM (Joux 2006) permet à un attaquant de récupérer H et de forger des tags. La page génère des IV avec `crypto.getRandomValues` (un CSPRNG), ne les réutilise jamais dans une session et préfixe l'IV au texte chiffré pour que le côté déchiffrement puisse le récupérer sans état hors bande.
• Génération de clé AES : le bouton de clé aléatoire utilise `crypto.getRandomValues` (CSPRNG du navigateur). Les rounds AES sont calculés via aes-js, une implémentation JavaScript pure compatible octet par octet avec libcrypto d'OpenSSL pour les mêmes paramètres de clé, IV et padding.
• Réalité des canaux auxiliaires : l'AES en JavaScript pur n'est pas à temps constant (l'indexage dans le tableau S-Box fuite le timing). L'AES de Web Crypto s'exécute en code natif et est à temps constant. Pour les charges de travail sensibles (HSM, KDF côté serveur), préférez le chemin natif ; pour un outil d'apprentissage dans le navigateur, aes-js convient car l'entrée est déjà en mémoire dans la page. Chemin de migration : SHA-1 → SHA-256 pour les hachages, DES → AES pour les chiffrements, ECB → GCM pour les modes.