Tous les articles
Sécurité9 min de lecture

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 Signal, 1Password, WireGuard et TLS. 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.

MB

Mathis Belouar-Pruvot

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, WireGuard, Signal 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 — une classe d'attaques appelée « padding oracle » (voir les attaques BEAST et Lucky 13 sur TLS 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, WireGuard, Signal, IPsec.
  • 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é compromise n'expose qu'un fichier, pas tout le coffre. C'est le modèle utilisé par Filarr — 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 en utilisant des clés par fichier. Le pipeline complet :

  • Votre mot de passe est étiré avec PBKDF2-SHA-512, 600 000 itérations (et Argon2id pour les profils plus récents) pour produire une Key Encryption Key (KEK)
  • Chaque fichier reçoit une File Encryption Key (FEK) aléatoire fraîche de 256 bits
  • Le fichier est chiffré avec sa FEK via AES-256-GCM, avec un nonce aléatoire par chiffrement
  • La FEK est chiffrée avec la KEK, aussi via AES-256-GCM, et stockée à côté du fichier

La KEK ne quitte jamais votre machine en clair. Les FEK n'existent jamais en clair sur le disque. Si nos serveurs de sync cloud sont compromis, tout ce qu'un attaquant voit est un flux de blobs chiffrés qu'il ne peut pas déchiffrer — les clés ne sont pas sur nos serveurs. Voir le modèle de sécurité Filarr pour l'architecture complète, le modèle de menace et les détails d'audit.

Pour aller plus loin

#aes#aes-256-gcm#chiffrement#cryptographie#chiffrement-authentifié