En ligne, la récupération de mot de passe a le plus souvent signifié confier votre fichier à un serveur distant et lui faire confiance. La récupération dans le navigateur inverse cette logique : l’archive ne quitte jamais votre appareil, et le travail cryptographique se déroule localement grâce à WebAssembly. Cet article explique comment cela est possible et pourquoi c’est une amélioration significative de la confidentialité.

L’ancien modèle : téléverser et espérer

Les outils de récupération en ligne classiques vous demandent de téléverser l’archive vers un serveur qui effectue le travail. Le problème est qu’un ZIP dont vous avez perdu l’accès est souvent exactement le genre de fichier que vous aimeriez le moins confier, comme des relevés financiers, des sauvegardes ou des documents personnels.

Une fois téléversé, ce fichier réside sur le disque de quelqu’un d’autre. Il peut être journalisé, mis en cache ou conservé, et vous n’avez aucun moyen de vérifier ce qui lui arrive réellement. Même lorsque le service a de bonnes intentions, téléverser des données sensibles ne fait qu’élargir le nombre d’endroits d’où elles peuvent fuir.

Le modèle du traitement local

Les navigateurs modernes peuvent faire tout ce dont la récupération a besoin sans serveur dans la boucle :

  • La File API lit directement les octets de l’archive depuis votre disque vers la mémoire de la page lorsque vous sélectionnez le fichier. Ces octets restent dans l’onglet du navigateur.
  • WebAssembly exécute la cryptographie lourde, notamment PBKDF2, HMAC et CRC, assez vite pour tester des mots de passe localement. Pour la dérivation de clé AES, l’outil chronomètre aussi l’API Web Crypto intégrée au navigateur et l’utilise à la place quand elle est plus rapide sur votre appareil.
  • Un groupe de Web Workers, un par cœur de processeur, exécute la recherche sur des threads en arrière-plan, de sorte que l’interface reste réactive. Les candidats des recherches par masque et par force brute sont générés dans les workers ; un dictionnaire que vous saisissez ou chargez leur est transmis depuis la page. Aucun d’eux ne passe par le réseau.

Rien dans ce pipeline n’exige d’envoyer votre fichier où que ce soit.

Pourquoi WebAssembly est important ici

La vérification d’un mot de passe AES est dominée par PBKDF2-HMAC-SHA1 avec 1000 itérations, calculé une fois par tentative. C’est une boucle numérique serrée, exactement le genre de travail que le JavaScript ordinaire effectue relativement lentement et que le WebAssembly compilé effectue rapidement. Exécuter le chemin critique en WebAssembly, ou dans l’API Web Crypto native du navigateur, plutôt qu’en JavaScript ordinaire est ce qui rend la récupération locale pratique plutôt que douloureusement lente. Cela ne change pas les mathématiques sous-jacentes, mais cela permet à votre propre matériel de tester bien plus de candidats par seconde.

Ce qui se passe réellement, étape par étape

  1. Vous choisissez un fichier. Le navigateur le lit localement, et le fichier n’est envoyé nulle part.
  2. La page analyse la structure de l’archive pour trouver ses entrées, détecter le schéma de chiffrement et choisir l’entrée que les workers testeront, de préférence la plus petite entrée chiffrée assez grande pour confirmer un mot de passe de façon décisive (parmi les entrées d’au plus 256 Mo compressés).
  3. Les candidats des recherches par masque et par force brute sont générés dans les workers ; une liste de mots (la vôtre et, si vous l’activez, la liste intégrée de mots de passe courants) leur est transmise depuis la page, et les workers ajoutent les variations que vous avez activées.
  4. Chaque candidat est vérifié d’abord avec le filtre bon marché, puis avec une vérification de confirmation pour tout survivant.
  5. Lorsqu’un mot de passe est confirmé, il vous est affiché, sur votre écran uniquement.

À aucun moment l’archive, un candidat ou le mot de passe final n’est transmis. L’étape de confirmation recalcule le HMAC pour AES, et déchiffre puis vérifie le CRC-32 pour une entrée ZipCrypto d’au moins 4 octets stockée ou compressée avec Deflate : sur une archive AES, un mauvais mot de passe n’est donc pratiquement jamais signalé, et sur presque toutes les archives ZipCrypto un mot de passe signalé a passé une vérification qu’un mauvais mot de passe franchit environ une fois sur 2^40 candidats, très rarement, mais pas jamais lors d’une très longue recherche. Quand seule une entrée ZipCrypto plus courte peut être testée, le résultat indique que le mot de passe n’a réussi qu’une vérification rapide. La page comment ça marche explique la rare exception et donne le tableau complet.

Pourquoi le traitement local est réellement plus confidentiel

  • Le fichier ne quitte jamais votre appareil, il n’y a donc aucun téléversement à intercepter, stocker ou faire fuir.
  • Les mots de passe testés ne sont ni journalisés ni transmis ; chaque candidat est testé dans un worker, puis écarté.
  • Il n’y a aucun enregistrement côté serveur des noms de vos fichiers ou de leur contenu, car aucun serveur ne les traite.

C’est le cœur de notre approche de la sécurité : la manière la plus confidentielle de traiter un fichier sensible est de ne pas le déplacer du tout.

Ce que l’outil conserve, et pour combien de temps

Parce que la récupération s’exécute à l’intérieur de la page, son empreinte est petite. Les octets de l’archive restent dans l’onglet tant qu’il est ouvert, chaque candidat est testé dans un worker puis écarté, et la progression comme les estimations de temps découlent de votre propre cadence de test. Deux éléments peuvent survivre à l’onglet, uniquement sur votre appareil. Un ZIP que vous déposez ou choisissez sur la page d’accueil attend dans le stockage du navigateur jusqu’à ce que la page de récupération l’ouvre et le supprime : il ne survit donc à l’onglet que si la page de récupération ne s’ouvre jamais. Et une recherche par masque ou par force brute en cours enregistre ses réglages (dont le nom et la taille du fichier et tout masque que vous avez saisi) et sa progression, pour que vous puissiez reprendre après un rechargement ou après avoir fermé l’onglet ; cet enregistrement est supprimé quand la recherche se termine, quand vous cliquez sur Arrêter ou quand vous choisissez Recommencer à zéro. Aucun des deux n’est jamais envoyé ; la politique de confidentialité détaille leur contenu et la façon de les effacer. Il n’y a ni compte ni historique de vos récupérations côté serveur.

Les limites honnêtes

Le traitement local est un gain de confidentialité, pas une baguette magique :

  • La vitesse dépend de votre propre matériel. Un ordinateur portable teste moins de candidats AES par seconde qu’une grosse machine, de sorte qu’un mot de passe robuste reste hors de portée, ce qui est tout l’intérêt du chiffrement.
  • La récupération dépend toujours du fait de réduire la recherche. Le traitement local change l’endroit où le travail se déroule, pas les mathématiques de la supposition.

Rien de tout cela ne change la recommandation, car le fait qu’un mot de passe robuste soit difficile à deviner est précisément ce qui protège vos données. Quand vous voulez essayer, tout s’exécute sur la page de récupération.

Vérifiez vous-même l’affirmation de confidentialité

Vous n’avez pas à croire quiconque sur parole :

  • Ouvrez les outils de développement de votre navigateur, passez à l’onglet Réseau, puis chargez un fichier et lancez une courte récupération. Vous verrez la page télécharger ses propres scripts, dont le worker et la sonde WebAssembly, et aucune requête qui emporte votre archive. La seule requête qui envoie des données est un POST vers /api/error, et seulement si le code du site rencontre une erreur ; elle contient le message d’erreur et la trace de pile, le chemin de la page et le user-agent de votre navigateur (la section 4 de la politique de confidentialité liste chaque champ), jamais de données de fichier ni de mot de passe.
  • Pour une seconde vérification, gardez l’onglet Réseau ouvert pendant cette recherche : vous ne verrez aucune requête vers un autre site et aucun téléversement de votre archive. Les requêtes que vous voyez vont vers ce site, comme le script que charge chaque worker, et aucune ne contient votre fichier ni un mot de passe.

Comme toujours, ne lancez la récupération que sur des archives que vous possédez ou que vous êtes autorisé à ouvrir.

En bref

  • La récupération dans le navigateur lit votre fichier localement avec la File API et ne le téléverse jamais.
  • WebAssembly rend la dérivation de clé AES lente suffisamment rapide pour s’exécuter sur votre propre appareil.
  • Des Web Workers maintiennent l’interface réactive, et aucun candidat ne passe par le réseau.
  • Vous pouvez vérifier vous-même que votre fichier ne quitte jamais votre machine.