Chargement...
Utilisez les flèches pour naviguer, Entrée pour sélectionner, Échap pour fermer le menu.
Chargement...
Chaque étape se déroule sur votre appareil. Nos serveurs ne voient que des données chiffrées — et ne peuvent rien en faire.
Saisissez du texte, collez un message ou importez un fichier — directement dans votre navigateur. À ce stade, rien n'a été envoyé. Vos données sont encore uniquement sur votre appareil.
Grâce à la Web Crypto API intégrée à tout navigateur actuel, vos données sont chiffrées avec AES-256-GCM. La clé est dérivée de votre phrase secrète sur votre appareil et ne le quitte jamais.
La sortie chiffrée apparaît instantanément. Si vous choisissez de la stocker, ce qui arrive sur nos serveurs est déjà chiffré — illisible sans votre clé. Vous contrôlez la suite.
Nous utilisons AES-256-GCM pour le chiffrement — la même norme que celle employée par les institutions financières et les agences gouvernementales. Les clés sont dérivées avec PBKDF2 (RFC 8018 / PKCS #5) et 100 000 itérations de HMAC-SHA-256. Ce nombre rend les attaques hors ligne à grande échelle coûteuses, mais c'est la solidité de votre phrase secrète qui compte le plus.
Toutes les opérations cryptographiques utilisent la Web Crypto API intégrée au navigateur. Vos données sont donc traitées localement avant toute communication réseau. Les données d'origine et vos clés de chiffrement ne quittent jamais votre appareil.
Les outils fonctionnent sans connexion internet une fois chargés. Aucun compte — les outils eux-mêmes ne collectent aucune donnée et leur utilisation n'est pas suivie. Les statistiques du site sont agrégées, sans cookie, et désactivées par défaut. Juste du chiffrement.
Trois mécanismes déterminent la protection réelle d'un chiffrement dans le navigateur : la dérivation de la clé à partir de votre phrase secrète, la valeur d'authentification ajoutée au texte chiffré et les limites que le chiffrement ne franchit pas.
Votre phrase secrète n'est pas la clé de chiffrement. Elle passe d'abord par PBKDF2, la fonction de dérivation de clé à partir d'un mot de passe spécifiée dans la RFC 8018 et décrite pour cet usage dans NIST SP 800-132. La fonction combine la phrase secrète avec un sel aléatoire 100 000 fois, et le résultat final sert de clé AES. Le sel est régénéré à chaque opération et stocké à côté du texte chiffré. Il n'est pas secret, et il n'a pas besoin de l'être. Dans la Web Crypto API, cela correspond à un seul appel : crypto.subtle.deriveKey avec le hachage, le sel et le nombre d'itérations en paramètres.
Deux variables seulement fixent le coût d'une attaque par force brute : le nombre d'essais qu'un attaquant peut s'offrir et le prix de chaque essai. Un nombre d'itérations élevé renchérit chaque tentative. Une phrase secrète longue et imprévisible réduit le nombre de tentatives qui valent la peine. Les deux ensemble repoussent une recherche exhaustive bien au-delà de ce qu'un attaquant réaliste peut financer, alors qu'une phrase courante et courte reste bon marché à tester avec le même nombre d'itérations. Relever ce nombre ralentit chaque essai, mais une phrase secrète faible reste faible.
AES-256-GCM, défini dans NIST SP 800-38D, remplit deux fonctions à la fois. Il chiffre avec une clé de 256 bits et il ajoute une étiquette d'authentification de 128 bits, calculée sur le texte chiffré et sur les données associées qui restent en clair. Au déchiffrement, cette étiquette est recalculée puis comparée. Si un seul bit du texte chiffré a été modifié — par une défaillance de stockage, un téléchargement corrompu ou une altération volontaire —, la comparaison échoue et le déchiffrement renvoie une erreur au lieu d'un résultat plausible.
GCM impose aussi une règle stricte : un nonce ne doit jamais être réutilisé avec la même clé. Sinon, des relations entre deux messages deviennent visibles et la clé d'authentification elle-même peut être exposée. C'est pourquoi un nouveau nonce aléatoire est produit à chaque opération, plutôt que repris d'un compteur que l'on pourrait réinitialiser. L'authentification n'est pas une signature pour autant. Elle prouve que le texte chiffré a été créé avec votre clé. Elle ne dit rien sur l'identité de l'expéditeur.
Le chiffrement transforme les données ; il ne les duplique pas. Si l'unique copie du texte chiffré disparaît — supprimée, écrasée ou perdue avec un disque —, aucune phrase secrète ne la ramènera. Si la clé manque, les octets chiffrés ne valent plus rien mathématiquement. Il n'existe ni procédure de récupération, ni lien de réinitialisation, ni intervention possible du fournisseur, car le serveur ne détient que des données chiffrées. Traitez le texte chiffré et la clé comme deux éléments distincts, chacun avec sa propre copie.
La protection s'arrête également au poste de travail. Un logiciel malveillant, une extension de navigateur détournée ou un écran visible par un tiers la contournent entièrement, car le texte en clair existe sur l'appareil avant et après l'étape cryptographique. Les métadonnées ajoutent une autre limite : noms de fichiers, tailles, horodatages et durées de conservation restent généralement lisibles même quand le contenu ne l'est pas. Prévoyez ces angles morts avant de vous reposer uniquement sur le chiffrement.
Sans inscription, sans attente. Ouvrez les outils et commencez à chiffrer dès maintenant.