AES-256 : l’algorithme, ses modes et leurs limites

AES-256 est un algorithme de chiffrement par blocs à clé de 256 bits, normalisé dans la norme FIPS 197. Il transforme un bloc de données en texte chiffré à l’aide d’une clé. Le nombre 256 décrit la longueur de cette clé. Il ne dit rien de vos fichiers, de votre appareil ni de la personne qui la détient.

Deux autres choix pèsent autant que la taille de la clé. Le mode d’opération règle le traitement des données qui dépassent un bloc. La dérivation transforme votre phrase secrète en clé. AES-256-GCM est une combinaison possible, AES-256-CBC une autre. L’algorithme est le même, presque tout le reste diffère.

CBC enchaîne chaque bloc au précédent, ce qui masque les motifs du texte en clair. Seul, il ne détecte aucune altération : inverser des bits du texte chiffré cause des dégâts prévisibles, sans connaître la clé. GCM ajoute une étiquette d’authentification, décrite dans le NIST SP 800-38D. Un fichier modifié échoue alors au déchiffrement au lieu de livrer des données fausses.

Une seconde différence porte sur ce qui peut être réutilisé. CBC demande un vecteur d’initialisation aléatoire neuf pour chaque message. GCM demande un nonce qui ne se répète jamais sous la même clé. Réutiliser un nonce GCM briserait le schéma : les bibliothèques le produisent donc pour vous.

La longueur de clé ne dit rien de la façon dont la clé a été créée. Une phrase secrète courte ou réutilisée donne une clé aussi faible que cette phrase, quel que soit l’algorithme. PBKDF2, décrit dans le RFC 8018, ralentit les essais. Il ne sauve pas un mot de passe que n’importe qui peut retrouver.

Le chiffrement ne dit rien non plus des extrémités. Un logiciel malveillant sur l’appareil lit votre texte en clair avant tout calcul. Une extension qui accède à la page ou un script injecté font de même. Certaines métadonnées survivent aussi : la taille du fichier, les horodatages et l’existence du transfert restent souvent visibles.

L’API Web Crypto exécute AES-256-GCM dans le navigateur et sait garder une clé non exportable. Un script ne peut pas en relire les octets bruts. La page reçoit malgré tout votre phrase secrète, et tout code qui s’y exécute lit votre saisie. L’origine que vous chargez compte donc plus que le mode choisi.

Une clé non exportable aide dans un cas précis. Si quelqu’un copie plus tard le stockage ou une image mémoire, une clé jamais exportable s’extrait plus difficilement. Elle ne protège rien contre le code actif dans la page pendant la saisie, ni contre un appareil déjà compromis.

Demandez d’abord contre quoi vous vous défendez. Un ordinateur perdu, un dossier partagé et un fournisseur qui journalise tout appellent des conceptions différentes. Demandez ensuite qui doit déchiffrer. Si vous êtes seul à détenir la clé, un outil côté client en AES-256-GCM avec une longue phrase secrète couvre l’essentiel du risque. Si quelqu’un d’autre doit lire les données, l’échange de clés devient la difficulté.

Une règle utile : préférez un outil qui authentifie. Sans étiquette, un fichier corrompu ou modifié peut se déchiffrer en données fausses sans que la sortie vous prévienne. Cette défaillance reste silencieuse, et c’est justement pourquoi elle mérite d’être écartée à la conception.