Chiffrer un fichier, puis envoyer la clé par une autre route

Ce que l'outil fait réellement à ton fichier

Il vaut la peine d'être précis, car « AES-256 » sur un bouton ne dit presque rien — les mêmes trois lettres recouvrent des constructions excellentes et des constructions cassées. Celle-ci appelle l'implémentation WebCrypto du navigateur en mode AES-GCM, c'est-à-dire du chiffrement authentifié : il ne cache pas seulement le contenu, il prouve aussi que le contenu n'a pas été modifié. La clé fait 256 bits. L'étiquette d'authentification fait 128 bits, et tu peux le vérifier sans lire une ligne de code : un clair de 71 octets a donné un chiffré de 87 octets, exactement les seize octets supplémentaires que la RFC 5116 prévoit pour AES-256-GCM.

Une phrase de passe n'est pas une clé : il faut la transformer en clé. L'outil utilise PBKDF2-HMAC-SHA256 sur 150 000 itérations, avec un sel de 16 octets tiré de la source aléatoire cryptographique du navigateur. Le sel est neuf à chaque chiffrement, ce qui empêche une table précalculée de couvrir plusieurs fichiers d'un coup. Le nonce fait 12 octets et change lui aussi à chaque fois — vérifié en chiffrant deux fois le même fichier avec la même phrase et en comparant : sel différent, nonce différent, chiffré différent. Les deux sont stockés en clair en tête de la sortie, et c'est correct, pas négligent. Un sel et un nonce ne sont pas des secrets ; ils doivent seulement être uniques, et celui qui déchiffre en a besoin pour reconstruire la clé.

La moitié authentification n'est pas décorative. Retourne un seul bit n'importe où dans le chiffré et le déchiffrement refuse ; retourne un seul bit du nonce stocké et il refuse aussi ; donne une phrase de passe qui ne diffère que par une majuscule et il refuse. Dans tous les cas tu obtiens une erreur, jamais un fichier plein de déchets d'apparence plausible. Cette distinction compte plus qu'il n'y paraît : un mode sans authentification, comme AES-CBC sans contrôle d'intégrité séparé, rend des données abîmées sans broncher, et un attaquant capable de modifier le fichier en transit peut parfois orienter cette altération.

L'erreur que tout le monde fait : la clé voyage avec le fichier

Voici la forme que ça prend. Tu chiffres le tableau des salaires, tu joins le fichier .enc à un e-mail et — puisque le destinataire en a évidemment besoin — tu tapes la phrase de passe dans le même message. Ou dans un message de suivi, ce qui paraît plus prudent et ne l'est pas. Ou en réponse dans le même fil, ce qui est pire, car les deux moitiés sont désormais dans une seule conversation que la moindre recherche fera remonter ensemble. Quelle que soit la variante, tu as posé une serrure et scotché la clé sur la porte.

Si « je l'envoie dans un second e-mail » ne marche pas, c'est que cela ne change pas qui peut lire. Le chiffrement en transit n'est pas le modèle de menace ici — le courrier entre grands fournisseurs est déjà chiffré sur le fil. Ce contre quoi tu te défends réellement, c'est quelqu'un qui lit la boîte : un compte compromis, un téléphone laissé déverrouillé, une adresse familiale partagée, un employeur ayant un accès légal à l'archive, une sauvegarde fuitée, un fil transféré qui a ramassé un destinataire de trop. Chacun de ces cas expose le second e-mail exactement autant que le premier. Deux messages dans la même boîte, c'est un seul canal utilisé deux fois.

Ce qu'est réellement un second canal

Un second canal doit différer sur ce qui casse vraiment. Trois axes méritent d'être séparés. Un média différent — e-mail contre voix contre papier — pour qu'un protocole compromis ne livre pas les deux moitiés. Un compte différent — ta boîte professionnelle contre une messagerie personnelle — pour qu'un seul identifiant n'ouvre pas les deux. Et un appareil différent, pour qu'un téléphone volé ou infecté ne contienne pas le fichier et la phrase de passe côte à côte. Envoie le fichier depuis un portable et la phrase depuis l'application de messagerie du même portable, et tu as déplacé la clé de l'autre côté du bureau, pas hors de la pièce.

C'est pourquoi une phrase de passe dictée au téléphone est réellement meilleure, et pas seulement désuète. Elle ne laisse aucune copie : pas de message à rechercher plus tard, pas de sauvegarde qui fuit, pas de fil transféré par erreur, pas d'archive qu'un administrateur pourra ouvrir dans deux ans. L'intercepter suppose d'être sur la ligne au moment précis où elle est prononcée, ce qui est une attaque bien plus étroite et bien plus coûteuse que lire une boîte mail à loisir. Elle apporte aussi ce qu'aucun canal ne donne seul : tu reconnais la voix, donc tu sais qui a reçu. Dicte lentement, utilise l'alphabet OTAN pour tout ce qui est ambigu, et fais-la répéter.

Ce qu'on oublie : le destinataire doit pouvoir l'ouvrir

Un fichier chiffré que personne ne peut déchiffrer en face n'est pas de la sécurité, c'est une livraison ratée — et la réparation habituelle est pire que le problème d'origine, car elle finit par un renvoi du fichier en clair « juste cette fois ». Vérifie donc l'autre bout avant d'envoyer. Le fichier .enc produit par cet outil n'a aucun en-tête : ses premiers octets sont le sel aléatoire brut, sans nombre magique, sans version, sans nom d'algorithme et sans nom de fichier d'origine. C'est une disposition maison. Ce n'est ni un ZIP, ni un message OpenPGP, ni un fichier age, ni la sortie d'openssl enc — et aucun de ces outils ne l'ouvrira.

La conséquence pratique est bonne, cependant : comme l'outil tourne entièrement dans le navigateur, le destinataire n'a rien à installer, aucun compte à créer, aucun serveur à qui confier le fichier. Il ouvre la même page, charge le fichier .enc, tape la phrase de passe et clique sur déchiffrer, et le clair atterrit dans ses téléchargements. Rien n'est envoyé, dans un sens comme dans l'autre. La phrase à joindre au fichier n'est donc pas l'indice du mot de passe — c'est l'adresse de la page à ouvrir. Et envoie cette phrase-là par le même canal que le fichier, puisqu'elle n'est pas secrète ; seule la phrase de passe change de route.

Quand la phrase de passe est perdue

Rien ne peut être fait. Ni par le site, ni par un support, ni par toi. Il n'existe aucun compte gardant une copie, aucune clé de récupération, aucun séquestre et aucune porte dérobée — la clé n'a jamais existé ailleurs que dans la mémoire de l'onglet qui l'a fabriquée, et elle était dérivée de la phrase de passe à la volée. Perds la phrase et le fichier est un bloc de bruit qui restera du bruit. Cela mérite d'être dit franchement, car on suppose par défaut qu'un chemin de récupération existe, comme pour un mot de passe de webmail.

Et c'est le fonctionnement voulu, pas un échec. Un chemin de récupération est par définition une seconde entrée, et une seconde entrée est quelque chose qu'un attaquant peut emprunter aussi — ou qu'un tribunal peut contraindre quelqu'un à ouvrir. La bonne réponse n'est pas d'espérer une porte dérobée mais de ranger la phrase de passe quelque part de durable avant d'en avoir besoin : une fiche de gestionnaire de mots de passe rattachée au nom du fichier, ou du papier dans un tiroir si le fichier comptera encore dans cinq ans. Choisis une phrase que tu peux dicter, car il faudra sans doute le faire. Quatre ou cinq mots sans rapport battent un mot unique tordu sur les deux tableaux : c'est plus solide et cela survit à la lecture à voix haute.

Une faiblesse honnête : le nombre d'itérations

Ce n'est pas l'algorithme qui est le maillon le plus fin ici, c'est la dérivation de clé. PBKDF2 existe pour rendre la devinette coûteuse, et son coût est fixé par le nombre d'itérations. Cet outil en utilise 150 000. L'OWASP Password Storage Cheat Sheet, la référence dont partent la plupart des défenseurs, recommande aujourd'hui 600 000 pour PBKDF2-HMAC-SHA256. Le chiffre livré en représente le quart, ce qui multiplie par quatre le débit d'un attaquant qui devine hors ligne. Mesuré sur un cœur, 150 000 itérations demandent environ 36 millisecondes par essai : un cœur ordinaire teste donc à peu près 28 phrases par seconde ; du matériel spécialisé fait bien mieux, et PBKDF2 lui est plus favorable qu'une fonction gourmande en mémoire comme Argon2id.

Cela ne rend pas l'outil dangereux, et cela ne change rien à l'algorithme, au sel ni au nonce, qui sont justes. Cela déplace l'origine de la sécurité : avec une dérivation plus légère, la charge retombe davantage sur la phrase de passe elle-même. Une phrase de quatre mots tirés au hasard dans une grande liste reste hors d'atteinte dans les deux cas ; un mot du dictionnaire suivi d'un chiffre n'a jamais été protégé par le nombre d'itérations. Choisis la phrase comme s'il n'y avait aucun étirement, et l'écart entre 150 000 et 600 000 cesse de te concerner.

Questions fréquentes

AES-256-GCM suffit-il à lui seul ?

Pour le chiffrement lui-même, oui — c'est un mode authentifié standard et l'implémentation du navigateur est celle qui sert pour HTTPS. Mais un algorithme ne protège que ce que protège la clé. Ici la clé dérive de ta phrase de passe : le vrai plafond de solidité, c'est la phrase, et le vrai mode d'échec, c'est de l'envoyer par le même canal que le fichier. AES-256-GCM ne peut rien pour l'un ni pour l'autre.

Pourquoi le sel est-il en clair au début du fichier ?

Parce qu'il n'est pas secret et n'a jamais eu à l'être. Un sel existe pour que la même phrase de passe produise une clé différente à chaque fois, ce qui empêche une table précalculée d'attaquer plusieurs fichiers d'un coup. Il doit seulement être unique, pas caché. Idem pour le nonce. Celui qui déchiffre a besoin des deux pour reconstruire la clé : ils doivent donc voyager avec le chiffré — les cacher voudrait dire les chiffrer, ce qui demanderait une clé, et l'on tourne en rond.

Puis-je simplement envoyer la phrase de passe dans un second e-mail ?

Non, et c'est la version la plus répandue de l'erreur. Deux e-mails vers la même adresse atterrissent dans la même boîte, la même archive et la même sauvegarde. Qui peut lire l'un peut lire l'autre, et une recherche sur le nom de l'expéditeur les remonte côte à côte. Ce n'est pas un second canal, c'est le même canal utilisé deux fois. Change de média — la voix, ou une messagerie sur un autre compte — sinon le chiffrement n'achète que le temps de faire défiler l'écran.

Le destinataire peut-il ouvrir le .enc avec 7-Zip, GPG ou openssl ?

Non. Le conteneur est une disposition maison — 16 octets de sel, 12 octets de nonce, puis le chiffré et l'étiquette — sans nombre magique, sans octet de version et sans identifiant d'algorithme : aucun outil standard ne peut même le reconnaître. Le destinataire ouvre la même page dans son propre navigateur, charge le fichier, tape la phrase de passe et clique sur déchiffrer ; rien à installer, rien d'envoyé. Indique-lui la page à ouvrir dans le même message que le fichier. Cette partie-là n'est pas secrète.

J'ai perdu la phrase de passe — n'y a-t-il vraiment rien à faire ?

Vraiment rien. La clé n'a existé que dans l'onglet qui l'a créée, dérivée de la phrase de passe au moment du chiffrement ; aucune copie n'est conservée nulle part, par personne. Il n'y a ni clé de récupération, ni séquestre, ni recours au support, et cette absence est voulue — tout chemin de récupération est une seconde entrée, dont un attaquant pourrait se servir aussi. Si tu te souviens vaguement de la phrase, essayer des variantes à la main est ta seule option, et chaque essai coûte environ un vingtième de seconde.