Chiffrement AES — texte chiffré dans le navigateur

Que fait cet outil exactement ?

Vous saisissez un texte clair et une phrase de passe, l’outil chiffre les deux avec AES — symétriquement, c’est-à-dire que la même clé sert au chiffrement et au déchiffrement. En mode Déchiffrer, vous inversez l’opération. Tout s’exécute intégralement dans votre navigateur via la Web Cryptography API, une interface normalisée par le W3C que chaque navigateur moderne embarque depuis environ 2015. Aucun aller-retour serveur, aucun compte, aucun tracking. Vous pouvez charger la page hors ligne (PWA) et l’outil continue de fonctionner.

Sortie au format Base64 (compact, pratique pour le mail/chat) ou Hex (pratique pour les logs et les diffs de debug). La sortie réunit trois éléments bout à bout : un sel aléatoire pour la dérivation de clé, un vecteur d’initialisation (IV) aléatoire et le ciphertext lui-même. La disposition est documentée explicitement pour que vous puissiez déchiffrer le ciphertext avec OpenSSL, Python ou n’importe quelle autre pile compatible AES.

Pourquoi un AES navigateur plutôt qu’un outil en ligne ?

Trois des outils AES en ligne les plus consultés — aesencryption.net, encryption-decryption.online, devglan.com — acceptent votre texte clair et votre phrase de passe, puis les envoient par POST HTTPS à un serveur. Le serveur chiffre et renvoie le ciphertext. C’est absurde : un chiffre dont le but est de garder le texte clair secret fuite ce texte clair vers un serveur distant avant même de calculer. HTTPS protège la connexion, pas l’opérateur du serveur, pas les logs du fournisseur cloud, pas un attaquant ayant accès au serveur.

L’AES navigateur inverse cela. Votre texte clair et votre phrase de passe restent dans le contexte JavaScript de l’onglet du navigateur. Ils sont traités par l’API crypto.subtle, qui s’exécute à l’intérieur du moteur du navigateur — le même chemin de code que celui utilisé pour les handshakes TLS. Le ciphertext apparaît dans l’onglet. Vous le copiez, vous le partagez, le texte clair ne voyage jamais.

Pourquoi ces trois algorithmes, ni plus ni moins ?

AES-256-GCM est la valeur par défaut et la recommandation. AES (Advanced Encryption Standard) a été certifié NIST en 2001 (FIPS 197) et reste incassé — aucune méthode pratique connue ne réduit la force effective de la clé en dessous de la borne de force brute. Avec une clé de 256 bits, il reste confortable même face à l’algorithme quantique de Grover, qui ne ferait que ramener la sécurité effective à 128 bits — encore solide. GCM (Galois/Counter Mode) ajoute un tag d’authentification — toute manipulation du ciphertext est détectée au déchiffrement. Spécification : NIST SP 800-38D.

AES-128-GCM est la variante plus rapide avec une clé de 128 bits. Toujours solide ; pertinent quand la vitesse brute compte sur du matériel ancien ou embarqué. Pour la plupart des cas d’usage navigateur, la différence de vitesse est négligeable.

AES-256-CBC est le mode classique sans tag d’authentification. Le padding PKCS#7 permet de chiffrer n’importe quelle longueur de texte clair. Mise en garde importante affichée par l’outil : CBC NE détecte PAS l’altération du ciphertext. Un seul bit modifié déchiffre en données aberrantes sans lever d’erreur — dangereux quand les données sont consommées sans somme de contrôle séparée. Nous proposons CBC uniquement parce que beaucoup de systèmes hérités (vieilles applications Java, certains firmwares IoT) ne supportent que CBC. Pour des données nouvelles : préférez GCM.

Ce que nous ne proposons délibérément pas : AES-ECB (Electronic Codebook). ECB est cryptographiquement cassé car des blocs de texte clair identiques produisent un ciphertext identique, exposant les motifs du texte clair — la fameuse démo du pingouin ECB le montre : une image de Tux chiffrée en ECB laisse encore voir la silhouette du pingouin. Beaucoup d’outils en ligne listent ECB comme option, certains comme valeur par défaut. Nous le bloquons en dur.

Comment fonctionne PBKDF2 et pourquoi en ai-je besoin ?

Une phrase de passe n’est pas une clé. Une phrase de passe typique a 20 à 40 bits d’entropie ; AES en veut 128 ou 256. Combler cet écart est le rôle d’une fonction de dérivation de clé (KDF) — elle étire la phrase de passe à la longueur de clé complète et rend les tentatives de force brute coûteuses via de nombreuses opérations de hachage répétées.

Nous utilisons PBKDF2 avec SHA-256 comme fonction de hachage et 100 000 itérations. Cela correspond à la recommandation minimale OWASP 2024 pour PBKDF2-HMAC-SHA-256. Chaque chiffrement génère un sel aléatoire de 16 octets, stocké aux côtés du ciphertext. Le sel empêche les attaques par table arc-en-ciel : deux utilisateurs avec la même phrase de passe obtiennent des clés différentes.

Il existe des KDF plus modernes — Argon2 (vainqueur de la Password Hashing Competition 2015), scrypt (memory-hard) — qui résistent encore mieux à la force brute sur GPU. La Web Crypto API du navigateur ne supporte pas encore Argon2 nativement ; cela nécessiterait WebAssembly, ce qui briserait notre engagement zéro dépendance. PBKDF2 avec 100 000 itérations SHA-256 est suffisant pour un usage éducatif.

Que contient réellement le blob de sortie ?

La sortie du ciphertext est une concaténation de trois composants, encodés en Base64 ou Hex :

[sel:16 octets][IV:12 octets pour GCM, 16 octets pour CBC][ciphertext (+ tag auth 16 octets pour GCM):variable]

Au déchiffrement, l’outil lit les 16 premiers octets comme sel, les 12 suivants (ou 16 pour CBC) comme IV, et traite le reste comme ciphertext + tag d’authentification optionnel. Cette convention de disposition n’est pas normalisée par le NIST — différents outils AES utilisent des ordres différents. Nous la documentons explicitement pour que vous puissiez construire l’interopérabilité vous-même.

Déchiffrement externe avec Python (bibliothèque cryptography) :

import base64
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

blob = base64.b64decode("VOTRE_SORTIE_BASE64")
salt, iv, ct = blob[:16], blob[16:28], blob[28:]
kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=salt, iterations=100000)
key = kdf.derive(b"VOTRE_PHRASE_DE_PASSE")
plaintext = AESGCM(key).decrypt(iv, ct, None)
print(plaintext.decode("utf-8"))

OpenSSL CLI ne couvre pas directement cette disposition via openssl enc car OpenSSL utilise son propre préfixe de sel. Pour une compatibilité OpenSSL pure, il faudrait extraire sel et IV manuellement et appeler openssl enc -K <hex> -iv <hex> — fastidieux. Python ou Node sont les chemins ergonomiques.

Quelle est la sécurité réelle de la phrase de passe ?

La sécurité de l’ensemble du chiffrement repose sur la phrase de passe. AES-256 ne peut pas être cassé mathématiquement — mais si la phrase de passe est « Secret123 », un GPU la craque en quelques heures, peu importe la force du chiffre.

Règles pratiques pour 2026 :

• Moins de 8 caractères, une seule classe (minuscules seulement) : non sécurisé ; force brute en secondes à minutes.
• 8 à 11 caractères, classes mélangées : heures à jours contre un GPU moderne avec 100 000 itérations PBKDF2.
• 12 à 15 caractères, classes mélangées : semaines à mois. Acceptable pour des cas d’usage à faible menace.
• 16+ caractères, classes mélangées ou pattern Diceware : années à décennies. Recommandé.
• Diceware avec 6 mots tirés d’une liste de 7 776 mots : ~77 bits d’entropie, pratiquement incassable par force brute jusqu’aux années 2050 et au-delà.

L’indicateur de force sous le champ phrase de passe est une heuristique grossière (longueur + mix de classes), pas un estimateur de niveau zxcvbn. Il signale les entrées clairement faibles en rouge, les cas limites en jaune et donne le vert dès une longueur solide.

Ce que cet outil ne fait délibérément pas

Chiffrer des fichiers. Le MVP n’accepte que du texte. Le chiffrement de fichiers en masse est dans le backlog Phase-2 — il nécessite une lecture chunked + une UI de progression + une gestion de blob téléchargeable. Contournement aujourd’hui : encoder les petits fichiers en Base64 (built-in du navigateur ou notre Base64 Encoder) et chiffrer la chaîne Base64.

Crypto asymétrique. Cette classe (RSA, courbes elliptiques, PGP, age) a une UX fondamentalement différente : une clé publique et une clé privée, une gestion de clés, un modèle de confiance. Outil séparé si jamais besoin, pas à entasser dans l’outil AES.

Stockage cloud des clés. Anti-cas-d’usage. Un chiffre dont la clé vit sur le serveur de quelqu’un d’autre est une base de données cloud avec des étapes en plus.

Sel personnalisé ou IV personnalisé. Foot-gun. Les utilisateurs définiraient des IV statiques et détruiraient la garantie de sécurité. Volontairement non exposé.

Argon2 ou scrypt comme alternatives KDF. PBKDF2 est natif à la Web Crypto. Argon2 nécessiterait WebAssembly (libsodium) et alourdirait le bundle. À évaluer uniquement quand les modèles de menace l’exigent vraiment.

Usage éducatif — qu’est-ce que cela signifie en pratique ?

Cet outil est conçu pour un usage éducatif et personnel courant : garder secrète une courte note, partager un point de rendez-vous dans un chat, chiffrer une phrase d’API dans un carnet personnel, prendre en main le concept AES. Il n’est pas conçu pour :

• Le chiffrement de données personnelles imposé par le RGPD / HIPAA dans des contextes professionnels — il faut alors des jetons matériels certifiés, des signatures qualifiées, une gestion de clés documentée avec rotation et stratégie de sauvegarde.
• La défense contre des acteurs étatiques ou des services de renseignement — ces modèles de menace exigent des modules de sécurité matériels (HSM), des secure enclaves, des machines air-gapped, du forward secrecy au niveau protocole.
• Le chiffrement de conformité médicale, financière ou juridique — voir les exigences HIPAA, PCI-DSS, eIDAS.

Pour ces cas d’usage, les bons outils sont GnuPG (pour le chiffrement fichier/mail avec web-of-trust), age (moderne, plus svelte), HashiCorp Vault ou les équivalents AWS-KMS (pour la gestion de clés côté serveur), ou les services de signature qualifiée sous eIDAS.

Usage éducatif signifie : l’outil est mathématiquement correct, il utilise des primitives validées FIPS, la sortie est interopérable avec les piles cryptographiques professionnelles. Mais les hypothèses du modèle de menace — phrase de passe dans la tête, pas de HSM, pas d’audit log, pas de workflow de rotation de clés — ne conviennent qu’aux contextes à faible menace.

Comment se comporte la Web Crypto API sur les versions de navigateur ?

Stable et cross-browser depuis environ 2017. Précisément :

• Chrome / Edge : depuis la version 37 (2014).
• Firefox : depuis la version 34 (2014).
• Safari (macOS / iOS) : depuis Safari 11 / iOS 11 (2017).

Les méthodes utilisées ici (crypto.subtle.encrypt, crypto.subtle.decrypt, crypto.subtle.deriveKey, crypto.subtle.importKey, crypto.getRandomValues) sont toutes spécifiées dans la W3C Web Cryptography API Recommendation (2017) et entièrement implémentées dans chaque navigateur majeur. Sur mobile Safari iOS 11+ et Chrome Mobile, c’est la même chose. Aucun polyfill, aucun fallback.

Comment vérifier que le chiffre s’exécute vraiment localement ?

Ouvrez l’onglet Réseau des DevTools (Cmd+Option+I sur Mac, F12 sur Windows), exécutez un chiffrement — aucune requête réseau n’est émise. Le service worker installe le cache PWA, donc la page se charge hors ligne et l’AES continue de fonctionner. Le code source du composant est inspectable dans le navigateur (onglet Sources → AesVerschluesselungTool.svelte) — les appels crypto y sont directement traçables.

Un second contrôle de cohérence : dans la console DevTools, tapez crypto.subtle — vous devriez voir un objet SubtleCrypto. Les méthodes de cet objet sont implémentées dans le moteur du navigateur lui-même (C++ dans Chrome/Edge, en Rust + C++ dans Firefox, en Swift/C++ dans WebKit), pas en JavaScript chargé depuis un CDN. Quand cet outil appelle crypto.subtle.encrypt(...), le contrôle passe directement dans ces méthodes natives. Le texte clair ne traverse jamais un fetch(), n’atterrit jamais dans un corps de requête, n’est jamais sérialisé vers un serveur quelque part.

Pourquoi chaque chiffrement produit-il un ciphertext différent ?

Chiffrez deux fois le même texte clair avec la même phrase de passe, et les deux sorties sont complètement différentes. C’est délibéré et important. Chaque appel génère un sel aléatoire frais de 16 octets (donc une clé dérivée différente) et un IV aléatoire frais de 12 ou 16 octets. Sans cela, un attaquant qui observerait deux ciphertexts pourrait détecter que les textes clairs sont identiques — une fuite de métadonnée qui détruit la confidentialité pour des messages répétés.

Le sel et l’IV sont stockés aux côtés du ciphertext (dans l’en-tête du blob). Ils ne sont pas secrets — les garanties de sécurité d’AES-GCM tiennent tant que l’IV est unique par chiffrement sous une même clé, pas tant que l’IV est caché. Réutiliser le même IV sous la même clé avec GCM est une rupture catastrophique : cela fuit le XOR de deux textes clairs et permet la falsification du tag d’authentification. L’IV aléatoire par appel dans cet outil est la défense la plus importante contre ce piège.

Que se passe-t-il si je manipule le ciphertext ?

Pour AES-GCM (par défaut), l’outil le détecte. Le mode Galois/Counter ajoute un tag d’authentification de 16 octets à chaque ciphertext. Au déchiffrement, le tag est recalculé à partir du ciphertext + IV + clé et comparé. Si le ciphertext, l’IV ou la clé sont faux ne serait-ce que d’un bit, le tag recalculé ne correspond pas et l’API lève une OperationError — affichée comme « Decryption failed » dans l’UI. Vous ne pouvez pas obtenir de sortie de forme texte-clair en retournant des bits du ciphertext.

Pour AES-CBC, la manipulation passe inaperçue. Retournez un bit, déchiffrez et vous obtenez des données aberrantes en forme de texte clair pour ce bloc plus un retournement de bit exploitable dans le bloc suivant (attaque par bit-flipping en CBC). C’est précisément pourquoi GCM existe et pourquoi nous marquons CBC comme legacy. Si vous devez absolument utiliser CBC (interop avec de vieux systèmes), associez-le à un HMAC séparé sur le ciphertext — mais à ce stade, vous reconstruisez Encrypt-then-MAC à la main et vous feriez mieux de simplement utiliser GCM.

Qui en a réellement besoin au quotidien ?

• Les développeurs et développeuses qui veulent partager une phrase d’API, un point de rendez-vous ou un token de test en mail ou DM Slack sans monter un échange de clés PGP au préalable.
• Les enseignants et étudiants en cours de cryptographie, pour traverser AES en pratique : qu’est-ce qui change quand je modifie la phrase de passe, à quoi ressemblent les variations d’IV, que fait vraiment le padding PKCS#7.
• Les journalistes avec des contacts sources à faible menace qui veulent transférer une courte note depuis un carnet de recherche par e-mail.
• Les particuliers avec un carnet plein de mots de passe qui veulent sauvegarder le carnet dans le cloud, avec le texte clair restant hors ligne et le ciphertext partant sur iCloud / Dropbox / Drive.

Dans chaque cas : cet outil est un cran au-dessus de « texte clair dans le cloud » et un cran en-dessous de « workflow GnuPG avec HSM ». Il comble un vide que les outils en ligne avec aller-retour serveur ne peuvent tout simplement pas combler.

Questions fréquentes

Les réponses clés se trouvent dans le bloc FAQ ci-dessus — elles sont émises en JSON-LD FAQPage structuré pour les moteurs de recherche.

Quels outils sont liés ?

D’autres outils de l’écosystème kittokit qui s’intègrent dans le même contexte :

• Hash Generator — calculez des hashes MD5 / SHA-1 / SHA-256 / SHA-384 / SHA-512 de texte, intégralement dans le navigateur.
• Générateur de mots de passe — générez des phrases de passe aléatoires fortes, parfaites pour les clés AES.
• JWT Decoder — décodez des JWT sans aller-retour serveur.