Avant de déposer un fichier dans le cloud, qui peut lire le texte clair — et par quel canal envoyer la phrase secrète

Un paquet de certificats, un export RH, un fichier de config qui contient encore une clé privée : tout cela finit souvent dans Drive personnel ou dans le dossier partagé de l’équipe. La page d’envoi écrit « chiffrement en transit », « chiffrement au repos », « coffre-fort ». Ces formules nomment les disques et les tuyaux du fournisseur, pas « personne d’autre que vous ne peut l’ouvrir ». Un autre texte a déjà montré comment vérifier dans Réseau que le texte clair n’est pas parti : un slogan n’est pas une preuve. Ici, le décor est plus étroit — le fichier va quitter cet ordinateur et s’asseoir chez quelqu’un d’autre. D’abord, qui peut lire le texte clair. Ensuite, par quel canal la phrase secrète doit-elle passer.

Ce n’est pas une vitrine de « chiffrement de fichiers en ligne », ni un comparatif de clouds. Trois questions seulement : avant toute sortie, le texte clair est-il devenu texte chiffré ; après l’envoi, le fournisseur ou le prochain téléchargeur peut-il ouvrir le corps tel quel ; la phrase secrète a-t-elle voyagé dans le même message que le .lock ou le .enc. La page de chiffrement de MyPassGen travaille sur cette frontière : AES-256-GCM se termine dans le navigateur, puis vous téléchargez le résultat. Le fichier et la phrase secrète ne partent pas comme données métier. Tous les outils s’ouvrent sans compte. Le tableau et les étapes ci-dessous se vérifient sur place.

« Chiffré » désigne souvent la couche du fournisseur

HTTPS ne couvre que les oreilles sur le chemin. Une fois le fichier arrivé chez Drive, Dropbox ou OneDrive, le fournisseur peut encore le poser en clair, ou en texte chiffré qu’il sait ouvrir. Beaucoup de produits appellent ce chiffrement au repos à clés détenues par le fournisseur « vos fichiers sont chiffrés ». Pour l’exploitation, cela aide si un disque sort d’un datacenter. Pour « je ne veux pas que le stockage ouvre un scan de carte d’identité », ce n’est pas suffisant.

Chiffrer d’abord côté client, puis envoyer : c’est une autre couche. Le navigateur ou un programme local dérive une clé d’une phrase secrète que vous tenez. Le stockage garde du texte chiffré. Rclone Crypt, certains clients de synchro et Web Crypto dans un onglet appartiennent à cette couche. Ils répondent à « le stockage ne peut pas utiliser le corps ». Ils ne répondent pas à une phrase trop courte, à une phrase envoyée avec le fichier, ni à un nom de fichier qui dit déjà le contenu.

L’article 9 du RGPD, tel que le présente la CNIL, range les données biométriques destinées à identifier une personne, et d’autres données dites sensibles, parmi les traitements qui exigent une base légale particulière. Déposer un scan de passeport non chiffré dans Drive personnel, puis le renvoyer dans un groupe, c’est encore transférer le document d’identité. Chiffrer puis envoyer réduit qui peut ouvrir les octets. Ce n’est pas de l’anonymisation, et cela ne remplace pas « ce fichier doit-il quitter la machine ».

Qui peut lire le texte clair

Placez le même certs.zip dans le cloud et vous obtenez déjà trois classes. La différence n’est pas la phrase marketing. C’est qui tient la clé, et si le texte clair a quitté le navigateur avant l’envoi.

Seule la troisième classe répond à « je ne veux pas que le stockage voie le corps ». Le chiffrement doit finir avant l’envoi, et la clé ne doit pas être remise à cette machine de stockage. L’article précédent le disait déjà : la Web Crypto API garantit que le calcul peut se faire sur cet appareil. Elle n’interdit pas à une page d’envoyer d’abord et de chiffrer ensuite. « Chiffrer localement d’abord » se vérifie dans le trafic. Pas dans un slogan.

Ce que fait AES-256-GCM à cette étape

La première version de MyPassGen n’utilise que AES-256-GCM. NIST SP 800-38D spécifie GCM comme chiffrement authentifié : si le texte chiffré a été altéré, le déchiffrement doit échouer. Vous n’obtenez pas un corps brouillé que l’on pourrait encore prendre pour un document. RFC 5116 AEAD_AES_256_GCM utilise une clé de 32 octets, un nonce de 12 octets et une étiquette d’authentification de 16 octets. AesGcmParams sur MDN recommande de même un IV de 96 bits, et chaque chiffrement sous la même clé doit recevoir un IV neuf. L’IV n’est pas un secret. Il peut voyager avec le texte chiffré.

La phrase secrète n’est pas utilisée comme clé AES. La page fichier de ce site enchaîne PBKDF2, 100 000 itérations, SHA-256 et un sel de 16 octets, puis une clé de 256 bits. Le sel vit dans l’en-tête pour que le déchiffrement recalcule la même clé. RFC 8018 cite NIST SP 800-132 : le nombre d’itérations doit être aussi élevé que le temps d’attente acceptable le permet. Le conseil actuel d’OWASP pour des empreintes de mots de passe stockées côté serveur est PBKDF2-HMAC-SHA256 à au moins 600 000 itérations. C’est un autre métier. La première ligne de défense d’une phrase de fichier reste une chaîne longue et aléatoire. Le nombre d’itérations ralentit le tâtonnement hors ligne. Il ne sauve pas 123456 écrit dans un commentaire Drive.

La phrase secrète ne voyage pas avec le texte chiffré

L’échec habituel n’est pas le mauvais algorithme. C’est d’envoyer backup.lock et « la phrase, c’est l’été plus le matricule » dans le même fil Slack, le même e-mail, ou un readme.txt posé dans le même dossier Drive. Le stockage, ou n’importe qui dans ce canal, tient alors les deux moitiés. Le chiffrement local n’a rien fait.

Une séparation plus saine : le texte chiffré passe par Drive ou en pièce jointe ; la phrase secrète prend un autre canal — de vive voix, au téléphone, ou via un lien à usage unique (la clé reste après # dans l’URL ; la page de lecture n’exige pas de compte). Ne mettez pas la phrase dans le nom de fichier, dans un commentaire de zip, ni dans une note « visible seulement par moi » qui vit encore sous le même compte cloud.

Générez la phrase secrète sur cette machine avec le générateur de mot de passe. Le mode aléatoire va de 6 à 128 caractères, 16 par défaut. En dessous de 8, tenez-la pour faible. Une phrase oubliée ne se récupère pas : il n’existe pas de copie en clair côté serveur, ni de questions secrètes. C’est le prix pour que le stockage ne voie pas le corps. Ce n’est pas une fonction manquante.

Ce qu’un fichier .lock laisse encore voir

Le texte chiffré n’est pas « le fichier entier devenu du bruit illisible ». Un en-tête de conteneur public porte souvent encore des métadonnées. MyPassGen écrit .lock par défaut et peut aussi écrire .enc — le même format, une autre extension, pour coller aux habitudes d’autres outils. L’en-tête commence par quatre octets CSLK, puis une version, un sel de 16 octets, une taille de bloc, et le nom d’origine plus le type MIME en clair. Le corps est de l’AES-GCM par blocs d’environ 1 Mo. Chaque bloc porte son propre IV de 12 octets et son étiquette de 16 octets.

Donc, si vous chiffrez scan-carte-identite.pdf en scan-carte-identite.pdf.lock et que vous l’envoyez, la liste Drive et l’en-tête disent encore « ceci est une pièce d’identité ». Le chiffrement protège les octets du corps, pas le nom. Quand le nom est sensible, renommez l’original en quelque chose d’insignifiant avant de chiffrer. Ne donnez pas non plus un titre lisible au .lock envoyé.

Un fichier peut aller jusqu’à 5 Go. Le chiffrement découpe avec Blob.slice en environ 1 Mo, puis passe chaque tranche à crypto.subtle.encrypt. L’encrypt() de Web Crypto n’accepte qu’un BufferSource à la fois. Nourrir tout le fichier d’un coup cloue la mémoire d’un gros onglet. Le découpage évite « donner tout le texte clair à l’API d’un seul tenant ». Le résultat se rassemble encore sur cette machine pour le téléchargement. Le déchiffrement lit aujourd’hui tout le .lock d’abord : un très gros fichier coûte plus de mémoire — c’est un fait visible dans le moniteur du système, pas un slogan.

Vérifier sur place

Les étapes ci-dessous ne dépendent d’aucune promesse de marque. Utilisez un petit fichier texte jetable. Ne vous entraînez pas sur un vrai scan de pièce.

1. Créez un probe.txt de quelques dizaines d’octets et écrivez une phrase de test que vous seuls connaissez, par exemple orange-lake-7. N’utilisez ni une vraie phrase secrète, ni un numéro de pièce.
2. Ouvrez les outils de développement → Réseau et cochez « Conserver les journaux ». Ouvrez la page de chiffrement, choisissez ce fichier, définissez une phrase secrète, lancez le chiffrement.
3. Lisez chaque Fetch / XHR : la ligne de requête et le corps ne doivent contenir ni orange-lake-7, ni la phrase que vous venez de taper. L’analytics ne doit pas emporter l’original non plus. Scripts, styles et stats sans corps de fichier sont autorisés.
4. Téléchargez le .lock ou le .enc. Dans un éditeur hexadécimal, les quatre premiers octets de l’en-tête doivent être 43 53 4C 4B (ASCII CSLK). Plus loin, vous devez encore voir le nom d’origine probe.txt en clair — pas la phrase de test elle-même.
5. Reposez ce texte chiffré sur la même page. La bonne phrase doit restituer la phrase de test. Changez un caractère de la phrase : le déchiffrement doit échouer. Vous ne devez pas obtenir un corps brouillé.
6. Alors seulement, envoyez le .lock vers Drive ou Dropbox. Transmettez la phrase secrète dans un autre message. Ouvrez l’aperçu cloud : sans la phrase, l’original ne s’ouvre pas.

La page Chiffrer de MyPassGen travaille sur cette frontière : AES-256-GCM, PBKDF2 à 100 000 itérations, un fichier jusqu’à 5 Go, sortie .lock / .enc. Le calcul se termine dans l’onglet courant. Vous ne créez pas de compte. Ce que vous croyez, ce sont encore Réseau et l’en-tête, pas les cinq mots « nous n’envoyons rien ».

Un secret court n’a pas besoin de devenir un fichier

Une clé API, un code de récupération ou un mot de passe de base n’a pas besoin de devenir un fichier d’abord. Le chemin fichier entier convient aux paquets de certificats, aux exports de tableur et aux tranches d’image disque. Un texte court va mieux sur un lien à usage unique : texte clair jusqu’à 32 Ko, le serveur ne garde que le texte chiffré, la clé reste après #, et vous pouvez fixer le nombre de lectures et le TTL. Créer et lire fonctionnent sans connexion.

Les notes sortantes sont un autre métier. Une URL avec utm_source suit quels paramètres retirer. Téléphones et numéros de pièce dans un ticket suivent quels champs masquer. Chiffrer un fichier répond à « le stockage n’ouvre pas le corps ». Cela ne répond pas à « cette discussion ne devrait pas porter un numéro complet ».

Erreurs fréquentes

« Le cloud dit chiffré, donc je suis le seul à pouvoir lire. » Quand le fournisseur tient ou gère les clés, l’exploitation, une réquisition et un compte volé voient encore un fichier utilisable. Chiffrez d’abord localement, et l’ensemble de ceux qui peuvent ouvrir se réduit aux personnes qui tiennent la phrase secrète.

« HTTPS protège déjà tout le trajet. » HTTPS s’arrête à l’entrée du fournisseur. Une fois le fichier posé, la frontière de protection change de mains. Ce que vous réduisez, c’est le texte clair dans la copie au repos.

« Renommer en .lock, c’est chiffrer. » Un fichier renommé qui n’est jamais passé par un chiffrement authentifié se cherche encore en clair dans un éditeur de texte. L’en-tête doit porter une magie convenue, et le corps ne doit pas s’ouvrir. Changer le suffixe seul ne fait rien.

« J’ai oublié la phrase ; le support peut la réinitialiser. » Un stockage sans connaissance n’a pas de copie de phrase côté serveur. Le pied de page n’offre pas non plus une boîte mail pour « réinitialiser une phrase de chiffrement ». La phrase vit dans votre gestionnaire de mots de passe, ou sur un autre canal que vous contrôlez.

Par où commencer

Commencez par le fichier que vous devez envoyer aujourd’hui. Faites les six étapes ci-dessus sur un petit fichier jetable. Confirmez que Réseau n’a pas l’original, que l’en-tête est CSLK, et qu’une mauvaise phrase échoue. Alors seulement, chiffrez le vrai fichier. Si le nom est sensible, renommez-le d’abord.

Envoyez le texte chiffré vers Drive ou en pièce jointe. Dites la phrase de vive voix, appelez, ou créez un lien à usage unique. Ne posez pas la phrase dans un fichier texte du même dossier. Après ce passage, vous pouvez déjà répondre au titre : le stockage ne devrait pas obtenir le texte clair ; la phrase secrète ne devrait pas voyager avec le texte chiffré ; l’en-tête peut encore montrer le nom d’origine, et ce nom demande sa propre étape.

Questions fréquentes

En quoi un « coffre » du fournisseur diffère-t-il d’un chiffrement local d’abord ?

Un coffre a généralement encore le fournisseur qui tient ou gère les clés. Connectez-vous au même compte et vous ouvrez le fichier. Après un chiffrement local, le stockage n’ouvre pas le corps sans la phrase secrète. Si le compte est volé, quelqu’un sans la phrase ne peut télécharger que du texte chiffré.

Si j’oublie la phrase secrète, puis-je encore déchiffrer ?

Non. Il n’existe pas de copie en clair ni de phrase côté serveur. Utilisez une phrase longue et aléatoire, et gardez-la dans votre propre gestionnaire de mots de passe. C’est le prix symétrique de « le stockage ne voit pas le corps ».

Quelle est la différence entre .lock et .enc ?

Sur ce site, c’est le même conteneur avec une autre extension. Le déchiffrement accepte les deux suffixes. Ne supposez pas que le .enc d’un autre programme utilise le même en-tête.

Faut-il un compte pour chiffrer ? Le fichier est-il envoyé ?

Aucun compte. Le risque de journal commence quand vous remettez l’original à un site qui chiffre à votre place. En local, le fichier et la phrase restent dans l’onglet courant. Ce que vous contrôlez : Réseau a-t-il envoyé un corps de fichier ou une phrase, et pouvez-vous encore chercher la phrase de test dans le .lock.