Vaulted
Audit de 5 minutes

Vérifie toi-même le chiffrement zero-knowledge de Vaulted

Ne fais pas confiance aux outils de sécurité — vérifie-les. Quatre tests dans le navigateur, aucune installation, cinq minutes.

La checklist en 60 secondes

Parcours-la d'abord. Le pas-à-pas détaillé ci-dessous couvre chaque étape en profondeur.

  1. 1

    Ouvrir les DevTools → onglet Network

    Dans Vaulted, appuie sur Cmd+Option+I (macOS) ou F12 (Windows/Linux). Passe à l'onglet Network et filtre par Fetch/XHR.

  2. 2

    Créer un secret et inspecter le POST

    Saisis une chaîne canari reconnaissable (par ex. CANARY-12345) et clique sur Create. Trouve la requête POST /api/secrets. Ouvre l'onglet Payload — tu ne verras que du texte chiffré (base64) et iv. Cherche ton canari dans le corps ; il n'y est pas.

  3. 3

    Inspecter le lien de partage

    Regarde le lien généré. La clé de déchiffrement se trouve après le # (le fragment d'URL). Conformément au RFC 3986, les navigateurs n'envoient jamais les fragments au serveur — ni dans les lignes de requête, ni dans les en-têtes, ni dans les référents.

  4. 4

    Confirmer que le déchiffrement s'exécute côté client

    Ouvre le lien dans un nouvel onglet. La réponse GET de /api/secrets/[id] ne renvoie que du texte chiffré. Dans le panneau Sources, cherche crypto.subtle.decrypt — cet appel s'exécute dans ton navigateur, pas sur notre serveur.

Ouvrir Vaulted et commencer →Lire le modèle de menaces

Ce que tu vérifies

L'affirmation de Vaulted est précise : le serveur ne voit jamais ton texte en clair ni ta clé de chiffrement. Cela se décompose en quatre propriétés observables :

  1. Le texte en clair n'apparaît dans aucune requête réseau.
  2. La clé de chiffrement n'apparaît dans aucune requête réseau.
  3. Le fragment d'URL (où vit la clé) n'atteint jamais le serveur.
  4. Les données côté serveur seules ne peuvent pas reconstituer le secret.

Si les quatre tiennent, l'architecture est zero-knowledge par construction — aucun langage marketing requis.

Test 1 — Le texte en clair ne traverse jamais le réseau

  1. Ouvre vaulted.fyi.
  2. Ouvre les DevTools et passe à l'onglet Network. Filtre par Fetch/XHR.
  3. Saisis une chaîne reconnaissable dans le champ du secret — quelque chose comme CANARY-12345.
  4. Clique sur Create.

Tu verras une seule POST vers /api/secrets. Clique dessus et regarde l'onglet Payload.

Le corps contient un champ ciphertext et un champ iv. Les deux sont des blobs encodés en base64url. Cherche CANARY-12345 dans la charge utile — il n'y est pas. Le texte en clair a été chiffré dans le navigateur avant que la requête ne parte.

Si tu veux être minutieux, règle la limitation réseau sur « Slow 3G » et recommence. Le texte chiffré ressemble toujours à du bruit ; le texte en clair reste introuvable.

Test 2 — La clé ne traverse jamais le réseau non plus

Après avoir créé le secret, Vaulted t'affiche un lien de partage. Il ressemble à ceci :

https://vaulted.fyi/s/abc123#dGhpcyBpcyBhIGtleQ
                              ^^^^^^^^^^^^^^^^^^^^
                              encryption key (base64url)

La partie après # est le fragment d'URL. Conformément au RFC 3986, les navigateurs traitent les fragments localement — ils n'apparaissent jamais dans les lignes de requête HTTP, les en-têtes ou les référents.

Pour le prouver :

  1. Copie le lien de partage.
  2. Ouvre-le dans un nouvel onglet avec l'onglet Network des DevTools ouvert.
  3. Trouve la requête GET /s/abc123.
  4. Regarde l'onglet Headers — URL de requête complète, aucun fragment.
  5. Regarde l'onglet Request — aucun fragment.
  6. Vérifie document.referrer sur la page suivante — fragment retiré.

La clé dont le destinataire a besoin pour déchiffrer le secret était dans l'URL, mais elle est restée dans son navigateur. Le serveur a vu GET /s/abc123 et rien de plus.

Test 3 — Le serveur seul ne peut pas déchiffrer

Ouvre un terminal et curl le secret directement :

curl https://vaulted.fyi/api/secrets/abc123

Tu récupéreras un JSON contenant ciphertext et iv. C'est l'intégralité de l'état côté serveur de ton secret.

Maintenant, essaie d'en tirer un sens. Sans la clé du fragment d'URL, tu ne peux pas. AES-256-GCM avec une clé aléatoire correctement générée est, à toutes fins pratiques, indiscernable d'un bruit aléatoire. Un export complet de la base de données des serveurs de Vaulted livrerait exactement ceci — des blobs chiffrés et des métadonnées.

C'est la définition littérale du zero-knowledge : le serveur stocke des données qu'il ne peut pas lire.

Test 4 — Le chiffrement se produit dans du JavaScript que tu peux voir

Vaulted utilise la Web Crypto API, une primitive du navigateur — il n'y a aucun WASM obfusqué ni module natif qui cache le travail. Tu peux regarder le chiffrement se produire.

  1. Dans les DevTools, ouvre l'onglet Sources.
  2. Cherche crypto.subtle.encrypt (utilise Cmd+Option+F pour la recherche globale).
  3. Place un point d'arrêt sur la ligne qui appelle crypto.subtle.encrypt.
  4. Déclenche une nouvelle création de secret.
  5. Le point d'arrêt se déclenche. Inspecte les arguments : tu verras ton texte en clair sous forme de Uint8Array, la clé AES-GCM et un nouvel IV aléatoire.
  6. Passe au-dessus de l'appel. Le résultat est le texte chiffré qui est envoyé.

Tu regardes désormais le texte en clair devenir texte chiffré, dans ton navigateur, avant toute requête réseau. Les données ne peuvent emprunter aucun autre chemin.

Ce que cela prouve

  • Aucun texte en clair ne quitte le navigateur. Test 1.
  • Aucune clé ne quitte le navigateur. Test 2.
  • Le serveur ne peut pas déchiffrer avec ce qu'il stocke. Test 3.
  • Le chiffrement est réel et s'effectue côté client. Test 4.

C'est l'intégralité de l'affirmation zero-knowledge, démontrée face à un système de production en fonctionnement, en cinq minutes.

Ce que cela ne prouve pas

La vérification est un travail honnête — il vaut la peine d'être clair sur ses limites.

  • Les tests prouvent le comportement à cet instant. Un futur changement de code pourrait casser cette propriété. Si tu as besoin d'une assurance continue, abonne-toi au changelog et relance les tests régulièrement.
  • Ils ne protègent pas contre ton propre appareil. Un enregistreur de frappe ou une extension de navigateur malveillante peut lire le texte en clair après déchiffrement. C'est hors du contrôle de toute application web.
  • Ils supposent que le JavaScript que tu as exécuté est le JavaScript que Vaulted sert. Un attaquant ciblé ayant compromis le CDN pourrait servir un bundle différent à un seul utilisateur. Subresource Integrity et les builds reproductibles atténuent cela ; consulte notre modèle de menaces pour tous les détails.

Aller plus loin

Si tu veux creuser davantage :

Le meilleur argument pour un outil de sécurité, ce n'est pas son marketing. C'est que tu puisses le démonter et confirmer qu'il fait ce qu'il prétend. Vaulted est conçu pour que tu le puisses.

Questions fréquentes

Des questions ou quelque chose qui cloche ? Écris à [email protected] — on publie notre politique de divulgation responsable et on répond sous 48 heures.
Partager un secret →