Parcourez la boîte à outils complète à l'index des outils – chaque outil s'exécute localement dans votre navigateur.
Pourquoi les outils de sécurité devraient être zéro connaissance
Les développeurs manipulent des secrets toute la journée : clés API, JWT, fichiers de configuration, données clients dans les fixtures de test. Dès que vous en collez un dans un outil web quelconque, il est sur le serveur de ce site.
La réponse classique – installer un outil CLI – a ses propres coûts : binaires spécifiques à la plateforme, risque de chaîne d'approvisionnement des paquets et friction qui fait retomber les gens dans des raccourcis non sécurisés.
Les outils web zéro connaissance comblent l'écart : ils s'exécutent dans votre navigateur avec l'API Web Crypto, gardent les données sur votre appareil et fonctionnent partout sans installation. L'exigence de confiance est simplement « la page est ce qu'elle prétend être » – ce qu'une construction reproductible, un site statique et une CSP stricte rendent vérifiable.
Ce guide cartographie la boîte à outils : ce que fait chaque catégorie, les algorithmes impliqués et les pièges à éviter.
Hachage : empreintes pour les données
Un hachage cryptographique est une empreinte à sens unique : la même entrée produit toujours le même résumé, et changer un bit change tout le résumé. Le hachage n'est pas du chiffrement – rien n'est récupérable depuis un hachage.
Utilisez les hachages pour vérifier l'intégrité des fichiers (téléchargements, sauvegardes), pour comparer des données sans les stocker (vérification de mots de passe à l'ancienne, déduplication) et pour empreinter du contenu.
Pour l'intégrité, SHA-256 est la norme. Pour les mots de passe, n'utilisez jamais SHA brut – utilisez un hachage lent et salé comme Argon2id, scrypt ou bcrypt, conçus pour résister à la force brute.
Un outil de hachage navigateur est idéal ici : hachez un fichier localement, comparez les sommes et n'envoyez jamais le fichier – ce qui compte quand le fichier lui-même est confidentiel.
Chiffrement : confidentialité avec une clé
Le chiffrement transforme des données en texte chiffré que seuls les détenteurs de clé peuvent lire. Le défaut moderne est le chiffrement authentifié : AES-256-GCM, qui combine à la fois confidentialité et intégrité.
Le chiffrement navigateur est pratique aujourd'hui car Web Crypto fournit nativement AES-GCM, RSA-OAEP, ECDH et PBKDF2. Un flux basé sur phrase de passe dérive la clé localement et ne l'envoie jamais.
Utilisez le chiffrement côté client pour : les fichiers et textes qui ne doivent pas atteindre un serveur, le partage de secrets hors bande et la construction de fonctionnalités zéro connaissance dans vos propres produits.
Remarque: Le chiffreur navigateur de ce site utilise AES-256-GCM avec dérivation de clé PBKDF2, sel et IV aléatoires par opération – les mêmes primitives qu'une application native utiliserait.
Encodage : représentation, pas sécurité
Base64, Base64URL, Hex et l'encodage URL changent la représentation des données. Ils n'offrent aucune confidentialité – n'importe qui peut les décoder – mais ils sont essentiels pour faire transiter des données binaires par des canaux texte.
La distinction qui compte pour les développeurs : Base64URL (la variante utilisée par JWT) remplace + et / par - et _, donc les valeurs encodées survivent aux URL et noms de fichiers. Choisir la mauvaise variante est un bug d'intégration classique.
Un encodeur local est pratique pour décoder une charge utile d'une ligne de journal ou d'un fichier de configuration sans le coller dans un service que vous ne contrôlez pas.
Débogage JWT : lisez avant de faire confiance
Les JWT apparaissent constamment dans les journaux, en-têtes et configurations. Un JWT est trois segments Base64URL – en-tête, payload, signature – et les deux premiers sont trivialement lisibles par n'importe qui, y compris le serveur dans lequel vous les collez.
Un décodeur JWT côté client vous montre les claims – exp, iat, nbf, iss, aud – sans envoyer le jeton. Cela compte car un jeton est un identifiant de type bearer dans de nombreux systèmes.
Rappelez-vous la règle : décoder n'est pas vérifier. Décoder lit les claims ; la vérification exige la clé publique de l'émetteur et contrôle la signature et tous les claims standard. Gardez les deux séparés dans votre modèle mental et dans votre code.
Génération : l'aléa fait correctement
Les mots de passe, UUID, secrets HMAC et QR codes ont tous besoin d'une source d'aléa ou d'un encodage standard. Le navigateur fournit crypto.getRandomValues pour l'aléa sécurisé, et la génération UUID v4/v7 est normalisée.
Un générateur local évite deux modes de défaillance : l'aléa fait main faible (Math.random n'est pas acceptable pour les secrets) et les générateurs tiers qui journalisent ce que vous générez.
Pour les mots de passe, générez avec l'entropie en tête – la longueur bat le théâtre de la complexité. Pour les identifiants, choisissez v4 pour l'impossibilité de deviner ou v7 pour les clés triables, et connaissez le compromis.
Comment vérifier un outil zéro connaissance
- Ouvrez le panneau réseau du navigateur et confirmez qu'aucune requête ne porte vos données – idéalement, aucune requête sortante n'a lieu quand vous utilisez l'outil
- Déconnectez-vous du réseau et confirmez que l'outil fonctionne toujours – le code côté client continue de fonctionner hors ligne
- Privilégiez les outils côté client, statiques et reproductibles plutôt qu'une boîte noire
- Consultez la page du modèle de sécurité pour une déclaration honnête de ce qui est et n'est pas protégé
- Vérifiez que la page est servie en HTTPS et depuis le domaine que vous avez l'intention d'utiliser
Avertissement: Un outil « sécurisé » qui envoie votre texte clair va à l'encontre du but. L'onglet réseau est l'audit le plus rapide que vous puissiez faire – faites-le une fois par outil dont vous dépendez.
FAQ
Q.Outils navigateur ou outils CLI ?
A.Les deux ont leur place. Les CLI sont scriptables et fonctionnent dans le CI. Les outils navigateur gagnent pour les opérations ponctuelles avec des données sensibles car il n'y a rien à installer, rien à craindre dans la chaîne d'approvisionnement, et les données restent locales. Pour l'automatisation, utilisez un CLI bien audité.
Q.Comment faire confiance à un outil web avec mes données ?
A.Vérifiez qu'il est vraiment côté client : consultez l'onglet réseau, essayez hors ligne et lisez la source si elle est ouverte. Les outils de ce site sont statiques et ne font aucune requête réseau avec votre entrée.
Q.Math.random() est-il assez bon pour la sécurité ?
A.Non. Math.random n'est pas cryptographiquement sécurisé et ne doit jamais être utilisé pour des clés, jetons ou mots de passe. Utilisez crypto.getRandomValues (navigateur) ou l'équivalent CSPRNG au niveau OS (Node/autres plateformes).
Q.Ces outils stockent-ils mes données ?
A.Les outils axés sur la vie privée ne persistent pas votre entrée – pas de localStorage, pas de cookies, pas de copies côté serveur. Les données vivent dans la mémoire du navigateur pour la session et disparaissent à la fermeture de la page.
Q.Quel outil apprendre en premier ?
A.Commencez par le hachage (intégrité) et le chiffrement (confidentialité) – ils couvrent les deux besoins développeur les plus courants. Ajoutez ensuite le décodage JWT et l'encodage, que vous rencontrerez dans le débogage quotidien.
Références
- API W3C Web Cryptography : https://www.w3.org/TR/WebCryptoAPI/
- NIST FIPS 180-4 – Secure Hash Standard : https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
- RFC 7519 – JSON Web Token (JWT) : https://www.rfc-editor.org/rfc/rfc7519
- Aide-mémoire OWASP sur le stockage cryptographique : https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
Ouvrez la boîte à outils de sécurité
21 outils côté client pour le chiffrement, le hachage, l'encodage et le débogage. Sans envoi, sans compte.
Une boîte à outils qui ne voit jamais vos données
Hachage, chiffrement, encodage, débogage JWT et génération sont les cinq catégories qui couvrent la plupart du travail de sécurité quotidien – et chacune peut s'exécuter localement dans votre navigateur.
Gardez l'habitude de vérifier les outils avant de leur confier des données. L'onglet réseau et le code source sont vos meilleurs amis.
Explorez la boîte à outils complète – chaque outil est côté client et gratuit.
Articles liés
Livre blanc technique de l'architecture zéro connaissance : comment vos données restent privées
Une exploration technique approfondie de l'architecture zéro connaissance, des preuves à divulgation nulle, des principes de confidentialité par conception et des stratégies d'utilisation pour les systèmes modernes préservant la vie privée.
Chiffrement côté client : guide développeur
Le chiffrement dans le navigateur est puissant et facile à mal faire. Ce guide couvre le modèle de menace, les primitives Web Crypto, la gestion des clés et une liste de vérification pour la production.
Architecture zéro connaissance
Un regard approfondi sur l'architecture zéro connaissance et pourquoi les outils ZeyroVault ne peuvent pas voir vos données.
Déchiffrer AES-256-GCM localement
Déchiffrer AES-256-GCM est simple lorsque vous disposez du mot de passe et des bonnes métadonnées. Voici la procédure exacte – et les erreurs qui font échouer le déchiffrement.
bcrypt vs Argon2 : choisir un hachage
bcrypt protège les mots de passe depuis des décennies ; Argon2 est la recommandation moderne, résistante à la mémoire. Voici la comparaison et quand utiliser chacun en 2026.
Impression de QR codes : bonnes pratiques
Un QR code qui ne se scanne pas sur papier est un lien cassé. Réglez la taille minimale, le contraste, la correction d'erreur et la zone de silence avant d'envoyer le fichier à l'impression.