# Sécurité de HideFile : comment fonctionne le chiffrement et où il s'arrête
HideFile chiffre vos fichiers dans le navigateur avec une clé dérivée de votre mot de passe, puis stocke le résultat chiffré à l'intérieur d'une photo, d'un PDF ou d'une vidéo ordinaire. Vos fichiers et votre mot de passe ne nous sont pas envoyés. Cette page nomme les algorithmes et les paramètres, énumère exactement ce que l'app envoie, et dit franchement quelles sont les limites, y compris celles qu'un lecteur attentif nous reprochera.
Deux idées permettent de ne pas se tromper sur le reste de la page. Le chiffrement est la couche de sécurité : sans le mot de passe, le contenu est illisible. Le fichier de couverture est un camouflage : il change l'apparence des octets chiffrés pour quelqu'un qui parcourt vos fichiers, et ne les rend pas invisibles pour quelqu'un qui les examine.
## Votre mot de passe devient une clé sur votre appareil
Quand vous créez un fichier verrouillé, HideFile transforme votre mot de passe en clé avec **Argon2id** (version 1.3), une fonction de dérivation de clé à forte consommation de mémoire. « À forte consommation de mémoire » signifie que chaque essai coûte un bloc de mémoire en plus du temps, de sorte que deviner reste lent même sur du matériel conçu pour deviner.
Le coût dépend de l'endroit où le fichier est créé. Dans un navigateur de bureau, Argon2id utilise 64 MiB de mémoire et 3 itérations sur une seule voie. Un navigateur qui se déclare comme téléphone ou tablette, ou qui dispose de 4 Go de mémoire ou moins, reçoit 19 MiB, 2 itérations et une seule voie, car un navigateur de téléphone ne peut pas dépenser 64 MiB à chaque déverrouillage sans risquer d'échouer. Ce réglage plus bas respecte la recommandation minimale de l'OWASP pour Argon2id. Les paramètres sont stockés dans le fichier verrouillé : un fichier créé sur un ordinateur de bureau conserve donc son coût de 64 MiB quand vous l'ouvrez sur un téléphone.
Chaque fichier verrouillé reçoit un sel aléatoire de 16 octets, stocké avec lui. Deux personnes qui choisissent le même mot de passe obtiennent quand même des clés différentes, si bien que personne ne peut précalculer une table d'essais unique et l'utiliser contre tous les fichiers.
## Vos fichiers sont scellés avec XChaCha20-Poly1305
La clé issue de votre mot de passe ne chiffre pas directement vos fichiers. Chaque fichier verrouillé a sa propre clé de fichier aléatoire de 256 bits, générée sur votre appareil. La clé du mot de passe enveloppe cette clé de fichier, et la clé de fichier scelle vos fichiers.
Le scellement utilise **XChaCha20-Poly1305**, un chiffrement authentifié : il garde le contenu privé et détecte toute altération. Les fichiers sont stockés sous forme d'enregistrements, chacun avec son propre nonce aléatoire de 192 bits et une balise d'authentification Poly1305. Si un enregistrement est modifié, par une copie endommagée ou volontairement, le déverrouillage échoue avec une erreur au lieu de renvoyer discrètement un contenu faux.
Un mot de passe, deux clés. La clé du mot de passe ne fait jamais qu'envelopper la clé de fichier.
Les deux algorithmes viennent des bibliothèques open source RustCrypto (les crates argon2 et chacha20poly1305). Notre propre noyau, écrit en Rust, les utilise et s'exécute dans votre navigateur compilé en WebAssembly. Le même noyau tourne partout où HideFile tourne : il y a donc une seule implémentation à examiner, et non une par plateforme.
Le mot de passe est la seule clé. La pause après Create locked file, c'est Argon2id qui travaille.
## Rien de ce que vous verrouillez n'est envoyé
Verrouiller, déverrouiller et enregistrer se font tous dans l'onglet du navigateur. Vos fichiers, leurs noms, votre mot de passe et les clés ne sont pas envoyés à un serveur HideFile, et il n'existe aucun serveur HideFile qui stocke des fichiers verrouillés. La seule exception est une fonctionnalité que vous activez vous-même : si vous connectez votre propre bucket compatible S3, comme Cloudflare R2, l'app envoie des octets chiffrés depuis votre appareil directement vers ce bucket, pas vers nous.
L'app conserve certaines choses dans le navigateur, sur votre appareil. Pour accélérer la réouverture, elle stocke une copie du dernier fichier verrouillé que vous avez ouvert, toujours chiffrée, pendant un jour au plus et jusqu'à 100 Mo. Les fichiers que vous enregistrez pour les réutiliser et la copie de travail d'un fichier ouvert se trouvent dans le stockage de fichiers privé du navigateur. Elle retient aussi des réglages comme le thème et l'affichage, ainsi que le nom, la taille et l'heure des dix dernières couvertures ouvertes, jamais le mot de passe. Effacer les données du site supprime tout cela. Sur un ordinateur partagé ou emprunté, faites-le quand vous avez terminé.
## Les mesures d'audience que nous envoyons ne contiennent aucune donnée de fichier
Nous utilisons PostHog pour compter l'utilisation, avec la capture automatique désactivée : les clics et le contenu des pages ne sont donc pas enregistrés. Voici ce qui est envoyé :
- Les pages vues : le chemin de la page et l'URL de provenance, votre navigateur et le type d'appareil, et la taille de l'écran.
- Un pays approximatif, que PostHog déduit de votre adresse IP à l'arrivée de la requête.
- Un identifiant aléatoire anonyme conservé dans votre navigateur, pour compter les visites répétées.
- Trois événements, `locked_file_created`, `locked_file_opened` et `locked_file_saved`, qui ne portent chacun que le type de couverture (png, jpeg, mp4 ou pdf) et la plateforme (web ou native).
Les noms de fichiers, les tailles, les nombres, les chemins, les mots de passe, les clés, les contenus et les messages d'erreur ne sont pas envoyés. Un bloqueur de contenu comme uBlock Origin bloque la mesure d'audience et l'app fonctionne de la même manière. Vous pouvez le vérifier vous-même : ouvrez les outils de développement de votre navigateur, surveillez l'onglet Réseau pendant que vous verrouillez et enregistrez un fichier, et cherchez toute requête qui transporterait vos fichiers. La [politique de confidentialité](https://hidefile.app/privacy) est la version qui fait foi de cette liste.
Ce qui reste sur votre appareil, et la courte liste de ce qui en sort.
## Le modèle de menace, énoncé en personnes
| Qui | Résultat | Pourquoi |
|---|---|---|
| Quelqu'un qui fait défiler votre téléphone, votre ordinateur portable ou votre disque cloud | Arrêté | Il voit une photo, un PDF ou une vidéo ordinaire, et rien qui s'appelle coffre-fort |
| Quelqu'un qui connaît le code de déverrouillage de votre téléphone | Arrêté | La couverture a son propre mot de passe, distinct du verrouillage de l'appareil |
| Quiconque a une copie de la couverture mais pas le mot de passe | Arrêté | Le contenu reste chiffré |
| Un examinateur judiciaire, ou quiconque connaît HideFile et vérifie de près | Non caché | Il peut voir que des données ont été ajoutées ; le contenu reste chiffré |
| Quelqu'un qui peut vous forcer à donner le mot de passe | Non arrêté | Aucun logiciel ne résout cela |
| Un logiciel malveillant, un enregistrement d'écran ou un observateur sur un appareil déverrouillé | Non arrêté | Tant que les fichiers sont ouverts, ils voient ce que vous voyez |
HideFile arrête les curieux occasionnels, pas les outils d'analyse judiciaire.
## Un outil d'analyse judiciaire peut voir que des données ont été ajoutées
HideFile n'essaie pas de dissimuler à un contrôle judiciaire la présence de données, et ne prétend pas le faire. Vos enregistrements chiffrés se trouvent dans la structure propre au fichier de couverture, où un lecteur normal les ignore. Un outil spécialisé, ou un examinateur qui sait quoi chercher, peut identifier que des enregistrements ont été ajoutés. La taille du fichier est un indice plus simple : un court cliché de vacances qui pèse plusieurs gigaoctets est inhabituel, et comparer la couverture à l'original intact montre aussitôt la différence.
Ce que l'examinateur obtient, c'est le fait que quelque chose est là, pas le contenu. Sans le mot de passe, les enregistrements restent scellés. C'est la frontière honnête : cacher à la vue de tous répond à une personne curieuse et à une fouille ordinaire, pas à un examinateur déterminé qui a votre appareil en main. Ce n'est pas le bon outil face à des fouilles à la frontière, à des examinateurs formés ou à une pression juridique.
La détection d'altération couvre les enregistrements scellés, pas chaque octet de la couverture. Une app qui réenregistre la couverture, en supprime les métadonnées ou la recompresse peut modifier l'image sans aucune alerte du chiffrement, et peut supprimer entièrement les enregistrements, ce qui détruit les fichiers qu'ils contiennent. Gardez la couverture sous forme de fichier.
## Il n'y a pas de récupération de mot de passe
Nous ne détenons pas votre mot de passe et ne pouvons pas le dériver d'un fichier verrouillé. Il n'y a ni lien de réinitialisation, ni code de récupération, ni procédure d'assistance capable d'ouvrir un fichier. Si le mot de passe est perdu, les fichiers qu'il protège sont perdus. C'est une propriété de la conception, et la raison pour laquelle quiconque détient une copie de votre couverture ne peut pas simplement nous demander de l'ouvrir.
## Ce qui n'est pas open source et pas audité
Le code source de HideFile n'est pas public, et aucun cabinet indépendant ne l'a audité. Les algorithmes sont standard, les bibliothèques qui les implémentent sont open source, et cette page ainsi que la [page sécurité](https://hidefile.app/security) de l'app donnent les paramètres, mais notre code qui les appelle ne peut pas être lu par des tiers aujourd'hui.
Cela compte. Un commentateur de Hacker News, réagissant à un autre outil fermé qui cache des données dans une photo, l'a dit en quatre mots : « no source code == no security » (pas de code source, pas de sécurité). D'autres dans cette communauté font remarquer qu'une app web est livrée à neuf par le serveur à chaque visite, de sorte que même un code source publié aurait besoin d'un moyen de confirmer que le code que vous exécutez lui correspond. Les deux remarques sont justes, et pour un lecteur qui retient ce critère, HideFile ne le satisfait pas encore. Nous préférons le dire plutôt que d'argumenter. Si vous trouvez une faille, écrivez à support@hidefile.app avec les étapes pour la reproduire et laissez-nous un délai raisonnable pour publier un correctif avant de la divulguer.
## Sources
- HideFile : [Comment HideFile vous protège](https://hidefile.app/security)
- HideFile : [Politique de confidentialité](https://hidefile.app/privacy)
- OWASP : [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
- RFC 9106 : [Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications](https://www.rfc-editor.org/rfc/rfc9106)
- RustCrypto : [argon2 crate](https://docs.rs/argon2) et [chacha20poly1305 crate](https://docs.rs/chacha20poly1305)
- Hacker News : [Show HN: a hardware-bound local password vault hidden in a photo](https://news.ycombinator.com/item?id=49508206), commentaire [49509561](https://news.ycombinator.com/item?id=49509561)
- Hacker News : [commentaire sur la livraison par navigateur d'apps chiffrées](https://news.ycombinator.com/item?id=19983075)
