Texte en clair

Utilise AES-256-GCM via la Web Crypto API. Un IV aléatoire de 96 bits et un sel de 128 bits sont générés à chaque chiffrement. Le mot de passe est dérivé via PBKDF2 (100 000 itérations, SHA-256).

Comment utiliser

1. Choisissez le mode Chiffrer ou Déchiffrer.
2. Saisissez votre texte et un mot de passe.
3. Cliquez sur le bouton d'action · le résultat apparaît ci-dessous.
4. Pour déchiffrer, collez la sortie chiffrée et utilisez le même mot de passe.

Questions fréquentes

Ce chiffrement est-il sûr ?

Oui. AES-256-GCM est un chiffrement de qualité militaire. Combiné à la dérivation de clé PBKDF2 (100 k itérations), il offre une protection robuste. La sécurité dépend toutefois de la force de votre mot de passe.

Pouvez-vous récupérer mon mot de passe ?

Non. Tout s'exécute dans votre navigateur. Nous ne voyons jamais votre texte ni votre mot de passe. Si vous perdez votre mot de passe, le texte chiffré ne peut pas être récupéré.

Quel est le format de la sortie ?

La sortie chiffrée est une chaîne Base64 qui contient le sel, l'IV et le texte chiffré. Il suffit de la recoller dans l'outil pour la déchiffrer.

Ce qui se passe réellement quand vous cliquez sur Chiffrer

Les chiffrements symétriques comme AES utilisent la même clé pour chiffrer et déchiffrer. Cela signifie que quiconque détient la clé peut à la fois verrouiller et déverrouiller les données, de sorte que tout l'enjeu de leur usage se réduit à une seule question : comment l'expéditeur et le destinataire partagent-ils la clé sans la divulguer ? La réponse de cet outil est « vous vous en chargez vous-même » : mettez-vous d'accord sur un mot de passe via un canal de confiance distinct, puis collez tous les deux la même chaîne ici.

En coulisses, l'outil exécute quatre étapes via la Web Crypto API native du navigateur :

1. Étirer votre mot de passe en une clé. Un mot de passe est une chaîne courte, à faible entropie ; une clé AES-256 fait 32 octets de données aléatoires à forte entropie. L'outil fait passer votre mot de passe par PBKDF2-HMAC-SHA-256 avec 100 000 itérations (spécifié dans la RFC 8018), plus un sel aléatoire de 128 bits. Le sel fait que chaque chiffrement produit une clé différente même si vous réutilisez le mot de passe, ce qui tue les attaques par tables arc-en-ciel. Le nombre d'itérations ralentit la recherche par force brute, attaque par attaque.
2. Générer un nonce neuf. Un IV aléatoire de 96 bits (la longueur recommandée par le NIST pour AES-GCM) est créé via crypto.getRandomValues : la même source d'aléa cryptographiquement sûr que le navigateur utilise pour le TLS.
3. Chiffrer avec AES-256-GCM. Le texte en clair est encodé en octets UTF-8 et passé à travers AES-256 en mode Galois/Counter, ce qui produit un texte chiffré plus une étiquette d'authentification de 128 bits.
4. Empaqueter et encoder en Base64. Le sel, l'IV et le texte chiffré+étiquette sont concaténés en un seul blob binaire et encodés en Base64, afin de voyager sans risque à travers un courriel, une messagerie ou tout autre support qui attend de l'ASCII.

Pourquoi AES-256-GCM en particulier

AES (Advanced Encryption Standard) est le chiffrement symétrique que le NIST a choisi en 2000 à l'issue d'un concours public comptant 15 candidats. La conception gagnante était Rijndael, des cryptographes belges Joan Daemen et Vincent Rijmen, formalisée sous le nom FIPS PUB 197 le 26 novembre 2001. Le NIST approuve trois tailles de clé (128, 192, 256 bits) et la NSA les approuve toutes les trois pour les données SECRET, AES-256 étant aussi approuvé pour le TOP SECRET. Après plus de deux décennies d'examen public, il n'existe toujours aucune attaque pratique contre une implémentation correcte d'AES : le chiffrement lui-même est essentiellement incassable, de sorte que l'argument de sécurité se déplace entièrement vers la gestion des clés et la robustesse du mot de passe.

Un chiffrement par blocs comme AES ne chiffre qu'un seul bloc de taille fixe de 128 bits, donc tout message réel nécessite un mode opératoire pour assembler les blocs. Le mode compte autant que le chiffrement. Le tristement célèbre ancien réglage par défaut, ECB : chiffre chaque bloc indépendamment, ce qui laisse fuir les motifs ; la célèbre image du « ECB Penguin », Tux encore reconnaissable après chiffrement, en est l'illustration d'avertissement classique. Beaucoup d'anciens outils « AES » en ligne exposent encore ECB ; celui-ci ne le fait pas.

GCM (Galois/Counter Mode), conçu par McGrew et Viega et normalisé par le NIST dans SP 800-38D (novembre 2007), combine un chiffrement en mode compteur avec une étiquette d'authentification sur corps de Galois. C'est un mode AEAD (Authenticated Encryption with Associated Data), c'est-à-dire qu'il assure la confidentialité et l'intégrité en une seule opération. Si un seul octet de la sortie chiffrée est inversé, le déchiffrement lève une erreur au lieu de renvoyer un texte en clair brouillé. C'est le même mode qu'utilisent TLS 1.2 et TLS 1.3. C'est véritablement le mode de prédilection de la cryptographie moderne d'Internet.

Un mot de passe n'est pas une clé

Une clé AES-256 fait 32 octets d'aléa uniforme. Le mot de passe d'un utilisateur (même solide) est court, surtout de l'ASCII imprimable, et se regroupe autour de motifs de dictionnaire. Vous ne pouvez pas fournir un mot de passe directement à AES sans aide. Cette aide est une fonction de dérivation de clé basée sur un mot de passe (KDF). PBKDF2, scrypt et Argon2 sont les trois que vous verrez dans le code moderne :

• PBKDF2 (RFC 8018), l'originale. Itère une fonction pseudo-aléatoire HMAC un grand nombre de fois. Rapide sur un processeur, mais pas exigeant en mémoire : les GPU et les ASIC cassent les empreintes PBKDF2 bien plus vite que le nombre d'itérations ne le laisserait croire sur un ordinateur normal. Cet outil utilise PBKDF2 parce que c'est la seule KDF de mot de passe que la Web Crypto API expose nativement ; Argon2 et scrypt nécessiteraient de livrer du JavaScript ou du WebAssembly supplémentaire.
• scrypt (RFC 7914, 2016, par Colin Percival) a ajouté la dureté mémoire : force un attaquant à allouer un grand bloc de RAM par tentative, ce qui défait le matériel parallèle bon marché.
• Argon2id (RFC 9106, 2021), lauréat du Password Hashing Competition de 2015 ; la recommandation de premier choix actuelle de l'OWASP. Exigeant en mémoire, résistant aux attaques par canaux auxiliaires.

Mise en garde honnête : 100 000 itérations PBKDF2 sont bien au-dessus du plancher original de la RFC de 1 000, mais en deçà des recommandations actuelles de l'OWASP pour 2026, qui sont de 600 000 pour PBKDF2-SHA-256. Le compromis est le temps de chiffrement sur les téléphones lents : à 600 000 itérations, dériver une clé sur un appareil Android d'entrée de gamme commence à ajouter une pause perceptible. Pour des secrets à enjeux élevés et à long terme, choisissez un mot de passe plus long pour compenser, ou utilisez un gestionnaire de mots de passe dédié, qui utilise généralement Argon2id avec des paramètres plus robustes.

Sel et IV : ils se ressemblent, mais font des choses différentes

• Le sel est une entrée de la dérivation de clé. Il rend la correspondance mot de passe→clé unique pour chaque chiffrement, de sorte qu'un texte chiffré volé ne peut pas être cassé à l'aide d'une table précalculée de clés de mots de passe courants. Le sel n'a pas besoin d'être secret, juste unique et imprévisible.
• L'IV / nonce est une entrée du mode de chiffrement. Pour AES-GCM en particulier, c'est le point de départ du compteur de 96 bits. Il doit être unique pour chaque paire (clé, message) ; en réutiliser un est catastrophique en GCM : cela permet à un attaquant de récupérer la clé GHASH et de forger des textes chiffrés arbitraires. L'outil génère un IV aléatoire neuf à partir de crypto.getRandomValues à chaque chiffrement, ce qui évite ce risque.

Quand l'utiliser, et quand ne pas le faire

Le bon outil lorsque :

• Vous devez partager un unique message secret via un canal non fiable (courriel, Slack, SMS, une application de notes) et vous disposez d'un canal de confiance distinct (un appel téléphonique, une rencontre en personne, une conversation Signal) où vous pouvez transmettre le mot de passe.
• Vous voulez chiffrer un extrait localement avant de le coller dans un document ou une application de prise de notes en nuage, de sorte que même si le fournisseur est compromis, le contenu reste illisible.
• Vous avez besoin d'une « enveloppe scellée » rattachée à un flux de travail avec un partenaire qui a convenu d'un mot de passe verbalement.

Le mauvais outil lorsque :

• Vous et votre destinataire n'avez aucun secret prépartagé ni aucun canal hors bande. Envoyer le mot de passe par le même canal que le texte chiffré est inutile : quiconque peut lire le texte chiffré peut lire le mot de passe aussi. C'est le classique problème de l'œuf et de la poule de la distribution des clés, que la cryptographie à clé publique existe pour résoudre.
• Vous avez besoin de la confidentialité persistante. Signal et TLS 1.3 produisent une clé éphémère différente pour chaque session, de sorte qu'une fuite aujourd'hui n'expose pas les messages passés. Un unique mot de passe fixe donne la propriété inverse : quiconque apprend le mot de passe peut déchiffrer chaque message que vous avez jamais chiffré avec lui.
• Vous devez prouver qui a chiffré quelque chose. AES avec un mot de passe partagé prouve la possession du mot de passe, et non la paternité. Pour les signatures numériques, utilisez PGP, age ou S/MIME.
• Vous chiffrez à grande échelle ou pour de nombreux destinataires. Chaque destinataire a besoin d'un mot de passe partagé séparément et la rotation est pénible. Les outils asymétriques (age, PGP) et les serveurs de clés de type Signal gèrent cela mieux.

Un modèle mental utile : AES avec un mot de passe est l'équivalent numérique d'un cadenas de valise combiné à un appel téléphonique pour partager la combinaison. Cela fonctionne parfaitement si vous pouvez faire confiance à l'appel téléphonique. Ce n'est pas un substitut à une messagerie chiffrée de bout en bout comme Signal, qui automatise l'échange de clés et fournit la confidentialité persistante grâce à son protocole Double Ratchet.

À quel point un mot de passe doit-il être « assez fort » ?

Parce que le chiffrement lui-même est incassable, toute la sécurité du dispositif repose sur votre mot de passe. Le calcul pertinent est l'entropie : H = L × log₂(N), où L est la longueur et N la taille du jeu de caractères dans lequel vous puisez au hasard. Exemples chiffrés :

• 8 lettres minuscules aléatoires → environ 37 bits. Cassable en quelques heures sur un GPU moderne.
• 8 caractères de casse mixte avec chiffres et symboles → environ 52 bits. De quelques heures à quelques jours aux vitesses actuelles.
• 12 caractères de casse mixte avec chiffres et symboles → environ 79 bits. Au-delà des budgets d'attaque réalistes dans un avenir prévisible.
• Six mots aléatoires d'une liste Diceware de 7 776 mots → environ 78 bits. À peu près la même sécurité que 12 caractères aléatoires, mais bien plus facile à mémoriser.

Les mots de passe choisis par des humains sont nettement plus faibles : des recherches citées dans les recommandations du NIST estiment la moyenne autour de 40 bits, ce qui explique pourquoi les attaques par dictionnaire l'emportent sur la pure force brute. Les conseils actuels de la NIST SP 800-63B pour les secrets mémorisés : au moins 8 caractères, en autoriser au moins 64, ne pas imposer de règles de composition (elles poussent les utilisateurs vers des motifs prévisibles comme Password1!), ne pas exiger de rotation périodique, et filtrer par rapport aux listes de mots de passe connus comme compromis. Visez « long, mémorisable, jamais apparu dans une fuite ». Une phrase de passe aléatoire de quatre à six mots que vous pouvez réellement retenir bat à tous les coups un mot de passe « complexe » de 8 caractères tarabiscoté.

Sa place parmi les autres outils de chiffrement

• TLS / HTTPS chiffre en transit entre vous et un serveur. Le serveur lui-même peut tout lire une fois que cela arrive. Résout le problème de l'espion, pas le problème du serveur.
• Signal / WhatsApp / iMessage sont un chiffrement de bout en bout complet, avec échange de clés automatique et confidentialité persistante. Résolvent les deux, mais exigent que les deux parties utilisent la même application.
• PGP / age sont asymétriques : vous chiffrez vers la clé publique publiée de quelqu'un sans avoir besoin d'un secret partagé au préalable. Résout la distribution des clés, mais historiquement pénible à utiliser ; age est l'alternative minimaliste moderne.
• Le chiffrement de disque au niveau du système (FileVault, BitLocker, LUKS) chiffre les données au repos sur un seul appareil à l'aide d'AES-XTS. Modèle de menace différent : protège contre le vol de l'appareil, pas contre l'interception réseau.
• Les gestionnaires de mots de passe utilisent AES-GCM (ou similaire) avec des KDF robustes (généralement Argon2id aujourd'hui) à l'intérieur d'un coffre chiffré qui synchronise le texte chiffré via un service du fournisseur incapable de le lire.

Un chiffreur de texte basé sur un mot de passe est le membre le moins spécialisé de cette famille : de la cryptographie pure, sans opinion sur l'identité, le transport ou le stockage. Ce minimalisme fait son attrait : c'est le bon outil lorsque vous avez précisément besoin de juste AES-256 avec un mot de passe et rien d'autre.

Plus de questions

Est-ce chiffré de bout en bout ?

En un sens, oui : le chiffrement se produit entièrement dans votre navigateur et Absolutool ne voit jamais le texte en clair ni le mot de passe. Au sens strict que les produits de messagerie comme Signal emploient, non : Signal fournit en plus un échange de clés asymétrique automatique et une liaison d'identité, de sorte que les utilisateurs n'ont pas besoin d'un canal de confiance distinct pour partager un mot de passe. Cet outil ne fait que la partie chiffrement sans ces extras, ce qui fait que la transmission du mot de passe relève de votre responsabilité.

Existe-t-il une récupération par « mot de passe oublié » ?

Non, par conception. L'outil ne voit jamais votre mot de passe et ne stocke jamais rien. Si vous perdez le mot de passe, le texte chiffré est irrécupérable. Enregistrez le mot de passe dans un gestionnaire de mots de passe ou notez-le quelque part sur un support physique.

Pourquoi la sortie chiffrée ressemble-t-elle à du Base64 aléatoire ?

Parce que c'est exactement ce que c'est. Le sel, l'IV et le texte chiffré-plus-étiquette-d'authentification sont concaténés en un seul blob binaire et encodés en Base64, afin que le résultat voyage sans risque à travers les systèmes qui attendent de l'ASCII imprimable (courriel, JSON, chaînes de requête). Les trois composants sont nécessaires au moment du déchiffrement, c'est pourquoi ils sont empaquetés ensemble : l'outil les ré-extrait lorsque vous recollez le blob.

AES-256 est-il illégal quelque part ?

La cryptographie grand public est largement légale dans pratiquement tous les produits grand public du monde en 2026. Les Crypto Wars américaines des années 1990 se sont terminées avec le décret 13026 (1996) et l'assouplissement pour le grand public de 2000. Des destinations spécifiques sous embargo (Iran, Corée du Nord, Syrie, Cuba) et une poignée de pays ayant leurs propres restrictions d'importation ou d'usage sur la cryptographie forte (la Chine, la Russie, le Vietnam et l'Arabie saoudite parmi eux) méritent encore d'être vérifiés au regard du droit local si vous utilisez l'outil dans ces juridictions.

Quelque chose est-il envoyé à un serveur ?

Non. La Web Crypto API s'exécute nativement dans le navigateur ; crypto.subtle appelle la même bibliothèque cryptographique que le navigateur utilise pour le TLS (BoringSSL sur Chrome, NSS sur Firefox, CommonCrypto sur Safari). Rien ne quitte votre appareil. La page exige aussi HTTPS, ce qui est imposé par le navigateur : la Web Crypto n'est disponible que dans les contextes sécurisés pour empêcher un attaquant réseau de remplacer le JavaScript avant son exécution.

Outils associés