Qu'est-ce que l'AES-256-GCM et pourquoi ça compte pour les apps de notes

L'AES-256-GCM est le mode de chiffrement authentifié utilisé par TLS 1.3, IPsec et 1Password. Voici ce que signifie chaque partie du nom, pourquoi GCM bat CBC, et ce qu'il faut vérifier quand une app de notes annonce du chiffrement AES-256.

Mathis Belouar-Pruvot

· fondateur de Filarr · · 10 min de lecture

Réponse rapide. L'AES-256-GCM est un mode de chiffrement authentifié qui combine AES-256 (le chiffre symétrique utilisé par les gouvernements, les banques et Signal) avec GCM (Galois/Counter Mode, qui ajoute la détection de falsification). C'est le mode utilisé par TLS 1.3, IPsec et 1Password. Une app de notes qui annonce « chiffrement AES-256 » doit préciser GCM (ou un autre mode authentifié) — l'AES-256-CBC sans authentification est un signal d'alarme.

Quand une app axée vie privée annonce « vos données sont protégées par chiffrement AES-256 », l'affirmation est incomplète. AES-256 est un chiffre, pas un schéma de chiffrement complet. Le mode opératoire compte autant que le chiffre lui-même — et un mode mal choisi peut rendre l'AES-256 effectivement inutile.

Cet article décompose l'AES-256-GCM en français simple : ce que fait chaque morceau, pourquoi il bat les modes plus anciens comme CBC, ses pièges connus, et ce qu'il faut vérifier quand une app de notes ou de stockage annonce l'utiliser.

Que signifie AES-256-GCM, morceau par morceau ?

Le nom a trois parties : AES, 256 et GCM. Chacune signifie quelque chose de précis.

AES (Advanced Encryption Standard) est un chiffre symétrique standardisé par l'institut NIST américain en 2001 (FIPS 197). « Symétrique » signifie que la même clé chiffre et déchiffre. AES est le chiffre le plus analysé au monde et reste non cassé sous sa forme complète.

256 est la longueur de clé en bits. AES est défini pour trois longueurs : 128, 192 et 256 bits. AES-256 est la variante la plus forte, avec un espace de clé de 2²⁵⁶ — astronomiquement plus grand que ce que toute attaque par force brute peut atteindre, même avec du matériel quantique imaginé (l'algorithme de Grover divise par deux la longueur effective, laissant à AES-256 une sécurité post-quantique de 2¹²⁸, toujours infaisable).

GCM (Galois/Counter Mode) est un mode opératoire. AES seul ne chiffre qu'un bloc unique de 128 bits. Pour chiffrer des données de longueur arbitraire, il faut un mode qui enchaîne les blocs. GCM est l'un de ces modes, et surtout il fournit du chiffrement authentifié avec données associées (AEAD) — il ne se contente pas de chiffrer vos données, il produit aussi un tag qui détecte toute falsification.

Mis ensemble, AES-256-GCM = « chiffrer avec AES, longueur de clé 256 bits, dans un mode qui détecte la falsification ».

Pourquoi GCM compte ? AES n'est-il pas déjà sécurisé ?

AES est sécurisé en tant que chiffre par bloc. Mais les chiffres par bloc sont inutilisables seuls — il faut un mode opératoire, et le choix du mode détermine les propriétés de sécurité du système entier.

L'erreur classique est d'utiliser AES en mode CBC sans authentification. CBC chiffre vos données correctement, mais ne vous dit pas si le texte chiffré a été falsifié. Un attaquant qui peut inverser des bits dans le blob chiffré peut corrompre votre texte en clair de manière prévisible, et c'est exactement ce qu'exploitent les attaques dites « padding oracle », comme Lucky 13 (voir Cloudflare sur les padding oracles et le déclin de CBC dans TLS, qui traite aussi de BEAST, une autre attaque qui ne touchait que CBC). Le déchiffrement réussit, mais vous récupérez un texte en clair falsifié.

GCM résout ça en calculant un tag MAC Galois (GMAC) à côté du texte chiffré. Au déchiffrement, si le tag ne correspond pas, le déchiffrement échoue — vous ne voyez jamais de texte en clair falsifié. C'est le chiffrement authentifié, et en 2026 c'est le seul choix acceptable pour les nouveaux systèmes.

ModeChiffre ?Détecte la falsification ?Statut
AES-ECBOui (mal)NonCassé — jamais utiliser
AES-CBC (sans MAC)OuiNonÀ éviter
AES-CBC + HMACOuiOui (si bien combinés)OK mais piégeux
AES-GCMOuiOui (intégré)Recommandé
AES-OCBOuiOui (intégré)Historiquement encombré de brevets
ChaCha20-Poly1305Oui (autre chiffre)Oui (intégré)Alternative tout aussi bonne

Comment GCM fonctionne réellement ?

GCM combine deux opérations :

  1. Chiffrement en mode compteur (CTR). GCM prend un nonce de 96 bits (« number used once »), concatène un compteur de 32 bits, chiffre ce bloc avec AES, et fait un XOR avec chaque bloc de texte en clair. Ça transforme AES en chiffre de flux. Chaque bloc utilise un compteur différent, donc des textes en clair identiques produisent des textes chiffrés différents.

  2. MAC en corps de Galois. En parallèle du chiffrement, GCM calcule un hash polynomial dans GF(2¹²⁸) sur le texte chiffré et toute donnée associée (en-têtes, métadonnées). Le résultat est un tag d'authentification de 128 bits ajouté au texte chiffré.

Pour déchiffrer, GCM reproduit le calcul GMAC, le compare au tag reçu, et ne procède au déchiffrement que si les tags correspondent. Un bit inversé dans le texte chiffré = désaccord de tag = déchiffrement refuse de retourner du texte en clair.

La performance est excellente : GCM est parallélisable (mode compteur), et les CPU modernes implémentent à la fois AES et la multiplication GF(2¹²⁸) en matériel (instructions Intel AES-NI et PCLMULQDQ). Sur un laptop de 2026, AES-256-GCM tourne à 5–10 Go/s.

Quel est le piège mortel d'AES-GCM ?

GCM a une règle critique, et la violer a des conséquences réelles : ne jamais réutiliser un nonce avec la même clé. Le nonce de 96 bits doit être unique pour chaque chiffrement effectué avec une clé donnée.

Si vous réutilisez un nonce, la confidentialité ET l'authenticité de GCM s'effondrent. Un attaquant qui voit deux textes chiffrés sous la même paire (clé, nonce) peut :

  • Faire un XOR entre eux pour révéler le XOR des textes en clair (n'importe quel mot connu d'un permet de casser l'autre)
  • Récupérer la sous-clé d'authentification GMAC, puis forger des textes chiffrés arbitraires qui se déchiffrent en n'importe quoi

C'est l'attaque interdite (forbidden attack), et c'est pourquoi les implémentations GCM doivent être prudentes. NIST SP 800-38D (le standard GCM) limite le nombre de chiffrements par clé à 2³² avant que le risque de réutilisation de nonce ne devienne inacceptable avec des nonces aléatoires.

Des conséquences réelles de réutilisation de nonce ont eu lieu — notamment dans certaines implémentations Bluetooth précoces, dans WPA2 (l'attaque KRACK), et dans des implémentations TLS précoces de GCM. Une implémentation correcte utilise soit un compteur déterministe, soit des nonces aléatoires par message avec des limites de rekeying documentées.

Quand on évalue le chiffrement d'une app de notes, la bonne question n'est pas « utilisez-vous AES-256-GCM ? » mais « comment dérivez-vous les nonces et à quelle fréquence faites-vous tourner les clés ? ».

Pourquoi les apps de notes utilisent AES-256-GCM ?

Pour les notes et les fichiers, AES-256-GCM est le bon choix parce que :

  • C'est standardisé. NIST SP 800-38D, utilisé dans TLS 1.3, IPsec et 1Password.
  • C'est rapide. Accéléré matériellement sur tous les CPU des dix dernières années.
  • Ça détecte la falsification. Si un serveur (ou un attaquant) modifie votre note chiffrée, le déchiffrement échoue immédiatement. Vous ne lisez jamais de texte en clair corrompu.
  • C'est disponible partout. Des implémentations existent dans le module crypto de Node.js, dans SubtleCrypto du navigateur, dans libsodium, OpenSSL, la stdlib de Go, la crate aes-gcm de Rust.

Pour une app de notes, le pattern typique est :

  1. Le mot de passe de l'utilisateur passe dans une fonction de dérivation de clé lente (PBKDF2 ou Argon2id) pour produire une clé maître — voir KEK et FEK expliqués.
  2. Chaque note (ou chaque fichier) reçoit sa propre clé de données aléatoire de 256 bits.
  3. La clé de données chiffre la note avec AES-256-GCM, en utilisant un nonce frais aléatoire ou compteur.
  4. La clé de données elle-même est chiffrée (« encapsulée ») avec la clé maître, aussi via AES-256-GCM.

Cette architecture par-clé-par-fichier signifie qu'une seule clé de fichier compromise n'expose qu'un fichier, pas tout le coffre. Filarr fait autrement : fichiers et notes sont chiffrés directement sous une clé de compte unique, avec un IV aléatoire nouveau à chaque fois, et seuls deux formats dérivent en plus une clé qui leur est propre (les gros fichiers importés sur le bureau, et les blocs synchronisés) — voir l'architecture de sécurité de Filarr pour les paramètres exacts.

Que vérifier dans une app de notes annonçant « chiffrement AES-256 » ?

Quand une app axée vie privée annonce du chiffrement AES-256, posez les questions suivantes :

  1. Quel mode ? GCM ou un autre mode authentifié est requis. CBC seul, ECB, ou « AES-256 » sans mode est un signal d'alarme.
  2. Comment la clé est-elle dérivée ? Du mot de passe directement ? C'est faux — les mots de passe ont trop peu d'entropie. Il doit y avoir une fonction de dérivation (PBKDF2, Argon2id, scrypt) avec des compteurs d'itérations documentés.
  3. Y a-t-il des clés par fichier, ou une seule clé globale ? Les clés par fichier (ou par note) limitent le rayon d'impact — une compromission unique n'expose pas tout.
  4. Comment les nonces sont-ils générés ? Compteur déterministe ? Aléatoire avec combien de bits ? « On utilise AES-GCM » sans discipline sur les nonces est fragile.
  5. Où le chiffrement est-il documenté ? Une app sérieuse publie son modèle de menace et son design de chiffrement. Si vous ne le trouvez pas, présumez du marketing-grade crypto.
  6. Le code est-il auditable ? Les implémentations open source laissent les chercheurs en sécurité vérifier les affirmations. AES-256 à code fermé est une promesse, pas une preuve.

Comment Filarr utilise AES-256-GCM ?

Filarr chiffre chaque fichier et chaque note avec AES-256-GCM sous la clé de votre compte. Le pipeline complet :

  • Votre mot de passe est étiré avec PBKDF2-SHA-512, 600 000 itérations (bien au-delà des 210 000 que l'OWASP recommande pour PBKDF2-SHA512) pour produire une Key Encryption Key (KEK)
  • Votre compte, ou votre profil local, possède une File Encryption Key (FEK) aléatoire de 256 bits
  • Chaque fichier et chaque note est chiffré via AES-256-GCM sous la FEK, avec un IV aléatoire nouveau à chaque fois ; les gros fichiers importés sur le bureau et les blocs synchronisés dérivent en plus de la FEK une clé qui leur est propre (HKDF-SHA256 avec un sel aléatoire)
  • La FEK est chiffrée avec la KEK, aussi via AES-256-GCM, et une seconde copie est encapsulée sous votre phrase de récupération

La KEK ne quitte jamais votre machine en clair, la FEK non plus. Si le stockage de notre sync cloud était volé, tout ce qu'un attaquant verrait est un flux de blobs chiffrés qu'il ne peut pas déchiffrer — nos serveurs ne détiennent votre clé qu'encapsulée. La limite connue, en voie de disparition : depuis le 16 octobre 2026, la connexion envoie une clé dérivée sur votre appareil, pas votre mot de passe ; pendant une transition d'environ deux mois, le mot de passe part encore vers nos serveurs pour un compte qui ne s'est pas reconnecté depuis, ou depuis une ancienne version de l'app, et un serveur compromis pourrait alors le capter. Voir le modèle de sécurité Filarr pour l'architecture complète et le modèle de menace.

Pour aller plus loin

Articles associés