D’abord la conclusion : un mot de passe ZIP ne prouve pas que « le cloud ne voit pas les fichiers ». Il montre seulement que l’extraction exige une phrase secrète. Le répertoire ZIP reste lisible par défaut, et le ZipCrypto classique peut livrer sa clé interne dès qu’un court morceau de texte en clair est connu. Avant d’envoyer, vérifiez deux choses : le contenu a-t-il déjà été scellé sur cet appareil avec un chiffrement authentifié, et cette requête HTTP a-t-elle emporté du texte en clair ou la phrase secrète.
Répondre à l’intention de recherche en une phrase
Protéger une archive par mot de passe avant un envoi cloud n’est pas la même couche que l’AES-GCM local. L’archive place les fichiers dans un conteneur ZIP et verrouille le contenu de ces fichiers. Le répertoire du conteneur — noms, dates, tailles — est conçu pour être lu. L’AES-256-GCM local passe par la Web Crypto API du navigateur sur les octets ; vous téléchargez le texte chiffré, puis vous l’envoyez. Sans votre phrase secrète, le cloud n’a que du bruit.
Cette note s’adresse aux développeurs, à l’exploitation, et à quiconque veut séparer « j’ai mis un mot de passe » de « l’autre côté ne peut pas lire le contenu » avant qu’une sauvegarde atterrisse dans Drive. Elle ne remplace pas le mode d’emploi pour chiffrer un fichier, et elle ne décrit pas les clics qui produisent un .lock. Ce qu’il faut emporter : ce que ZipCrypto et le ZIP-AES bloquent chacun, qui détient les clés cloud par défaut, ce qui reste dans l’en-tête d’un texte chiffré local, et comment contrôler Network et un dump hexadécimal sur cette exécution.
« J’ai mis un mot de passe » n’est pas « le cloud ne voit pas le contenu »
Le langage courant plie trois métiers différents dans « ce fichier est chiffré ». Le premier est le chiffrement en transit : le navigateur parle à Drive en HTTPS, un observateur sur le trajet a du mal à lire les octets. Le deuxième est le chiffrement au repos du prestataire : les blocs sur disque sont encapsulés avec des clés que le prestataire gère, ce qui aide si un disque est volé. Le troisième est le chiffrement côté client, avec une clé que vous détenez : le contenu est déjà du texte chiffré avant l’envoi, le prestataire ne peut pas l’ouvrir sans votre phrase secrète.
Un mot de passe ZIP relève d’une quatrième habitude : vous construisez sur cette machine un conteneur verrouillé par phrase secrète, puis vous l’envoyez comme un fichier ordinaire. Drive le traite comme n’importe quel .zip — indexation par nom, hachage pour le téléversement instantané, analyse malveillante ou de contenu sensible si la politique le demande. Si la charge utile est encore du ZipCrypto, ou si le répertoire est en clair, un scanner n’a pas besoin de « deviner votre mot de passe » pour lire les noms, et parfois il peut aller plus loin sur le contenu.
Donc « j’ai mis un mot de passe » ne soutient qu’une affirmation étroite : quelqu’un qui n’extraira pas, ou qui n’a pas la phrase secrète, n’ouvrira pas les fichiers facilement. Cela ne soutient pas « un employé Drive ne peut pas voir ceci », « une réquisition légale ne peut pas retrouver les originaux », ni « les noms n’entrent jamais dans leur index ». Ces phrases ne deviennent vérifiables qu’après un changement de couche : chiffrement authentifié sur cet appareil, puis envoi du texte chiffré.
Ce que ZipCrypto n’arrête pas
Le chiffrement ZIP classique s’appelle souvent Zip 2.0 ou ZipCrypto. L’aide de WinZip est nette : le format est relativement faible, et vous ne devez pas compter dessus face à quelqu’un qui a un outil de récupération dédié ; utilisez AES lorsque les fichiers comptent. C’est dans les notes de chiffrement WinZip, pas dans une rumeur de forum.
La faiblesse est le chiffre, pas la longueur de votre mot de passe. En 1994, Eli Biham et Paul Kocher ont publié une attaque à clair connu sur le chiffrement par flot PKZIP : avec une dizaine d’octets de texte en clair et de texte chiffré qui se correspondent, un attaquant récupère les trois états internes de 32 bits, puis le flux de clé pour le reste du fichier. La longueur du mot de passe sort de cette étape — le travail copie le cylindre de la serrure, il n’essaie pas les clés. Des outils publics comme bkcrack transforment cet article en programme ; les archives stockées (sans déflation) avec ZipCrypto sont le cas le plus direct. Des équipes françaises de cybersécurité décrivent la même attaque sous le nom d’attaque à clair connu, et rappellent que Windows, sans logiciel tiers, ne sait souvent extraire que du ZipCrypto — d’où la persistance de ce format.
D’où vient le clair connu ? Un PDF commence par %PDF. Les documents Office, beaucoup d’images et les ZIP imbriqués ont des magies fixes. Si vous glissez un format de document bien connu dans une archive ZipCrypto et que vous l’envoyez, vous avez aussi livré le texte chiffré plus un échantillon de clair presque certain. Ce n’est pas un mode d’emploi de l’attaque. C’est une raison d’arrêter de traiter « Compresser et définir un mot de passe » comme de l’AES-256-GCM.
Les compresseurs intégrés, une page Drive qui propose « chiffrer et zipper », et d’anciens scripts d’empaquetage choisissent souvent ZipCrypto parce que presque tous les extracteurs l’ouvrent. La commande zip -e de macOS et de beaucoup de distributions Linux tombe dans ce cas. Après l’empaquetage, lisez les propriétés : si c’est ZipCrypto ou Zip 2.0, n’en faites pas un plan de sauvegarde. Si c’est AES, passez à la section suivante — la couche contenu est plus solide ; le répertoire reste souvent en clair.
N’expérimentez pas avec un vrai contrat, un scan de pièce d’identité ou un dossier de projet non masqué. Préparez un petit fichier jetable. Placez un canari à usage unique dans le nom et dans le corps. Vous contrôlez le répertoire, l’en-tête et le trafic — pas besoin de renvoyer des données privées.
Même un ZIP AES montre encore le répertoire
WinZip propose AES-128 et AES-256 (AE-1 / AE-2) depuis la version 9.0. La clé vient de la phrase secrète via PBKDF2, avec un sel de 8, 12 ou 16 octets et 1 000 itérations. C’est un grand pas par rapport à ZipCrypto, mais ce n’est toujours pas « de l’AES-256-GCM dans le navigateur ». WinZip AES chiffre puis authentifie (AES-CTR plus HMAC). Ce n’est pas le GCM du NIST. Mille itérations sont aussi loin en dessous de la dérivation de mot de passe à cent mille itérations devenue courante. WinZip documente l’encapsulage sur sa page AES.
Le répertoire se rate plus facilement. WinZip indique que le chiffrement ne s’applique qu’au contenu des fichiers à l’intérieur de l’archive. Nom, date, taille, attributs et taux de compression vivent dans un répertoire non chiffré. Quiconque a le ZIP peut les lire sans mot de passe. Ils ont même publié une note sur « ouvrir un ZIP chiffré montre encore les noms », et suggèrent un double zip : empaqueter une fois sans chiffrement, puis placer cette archive dans un second ZIP chiffré. Voir la note WinZip sur la visibilité des noms.
Le format .7z de 7-Zip peut cocher « Chiffrer les noms de fichiers ». C’est une autre lignée de produit ; ne la mélangez pas avec le comportement ZIP par défaut. « Mot de passe requis » dans l’Explorateur signifie seulement que l’extraction exige une phrase secrète. Ouvrez le même fichier dans un autre extracteur et la liste apparaît souvent tout de suite : cni-verso.jpg, bulletin-paie-2026.xlsx, liste-clients.csv. Le téléversement instantané, l’aperçu et les analyses de politique lisent cette couche.
« Chiffré dans Drive » signifie le plus souvent que le prestataire détient les clés
Glissez un ZIP — ou le fichier d’origine — dans Drive, et la page parlera de chiffrement en transit, de chiffrement au repos, d’AES-256. Ces phrases peuvent toutes être vraies et ne pas répondre à qui détient la clé de désencapsulation. L’aide Drive de Google dit que les fichiers envoyés ou créés dans Docs / Sheets / Slides sont chiffrés en transit et au repos avec AES-256 par défaut. Si vous voulez aussi que Google ne puisse pas déchiffrer, un administrateur Workspace doit activer le chiffrement côté client, et l’utilisateur doit utiliser un compte professionnel ou scolaire et terminer la vérification d’identité. Un fichier personnel glissé dans Mon Drive suit le chemin par défaut, pas le chiffrement côté client. C’est dans l’aide Drive sur les fichiers chiffrés.
Google Cloud décrit le modèle au repos par défaut encore plus clairement : les clés sont détenues et gérées par Google. Les clés de chiffrement de données (DEK) sur disque sont encapsulées par des clés de chiffrement de clés (KEK) ; la désencapsulation a lieu dans le service de clés du prestataire. Voir le chiffrement au repos par défaut de Google Cloud. Les livres blancs Workspace tracent la même ligne entre « Google gère les clés » et « après chiffrement côté client, Google ne peut pas lire ». Les hachages de téléversement instantané, l’aperçu des documents et les analyses de conformité supposent que le serveur peut voir les octets du fichier — ou au moins un hachage du texte en clair. Un mot de passe ZIP local ne transforme pas cette pile en connaissance nulle.
Le cadenas d’un badge Drive protège donc « un disque sorti d’un centre de données » et « un observateur sur le trajet ». Il ne protège pas « après avoir remis ce fichier à cette entreprise, elle ne peut pas le voir non plus ». Cette deuxième phrase ne devient une observation qu’après la disparition de l’original lisible, avant l’envoi.
Quelle couche l’AES-256-GCM local protège réellement
AES-GCM est un chiffrement authentifié : une passe cache les octets et lie l’intégrité. Si le texte chiffré est altéré, tronqué, ou si la phrase secrète est fausse, le déchiffrement doit échouer franchement au lieu d’émettre « des déchets qui ressemblent à du clair ». Le NIST SP 800-38D recommande un IV de 96 bits (12 octets) pour un GCM interopérable ; l’étiquette fait souvent 128 bits (16 octets). Réutiliser un IV sous la même clé fait s’effondrer à la fois la confidentialité et l’authenticité.
Le chemin correct dans un navigateur est crypto.subtle.encrypt avec le nom d’algorithme AES-GCM. MDN indique que SubtleCrypto.encrypt n’est disponible que dans un contexte sécurisé — HTTPS en production. Une phrase secrète n’est pas une clé de 256 bits. Elle doit passer par une fonction comme PBKDF2, avec un sel et de nombreuses itérations. La RFC 2898 définit PBKDF2 ; le nombre d’itérations est le temps que prend une tentative. Mille et cent mille ne sont pas la même classe.
Un flux fichier se décrit par des gestes visibles : choisir un fichier local, le script le lit par blocs, chaque bloc reçoit un IV aléatoire neuf et de l’AES-256-GCM, puis le navigateur télécharge le texte chiffré. Ce téléchargement est assemblé sur cet appareil. Ce n’est pas un accusé du serveur. Une limite de 5 Go par fichier décrit le traitement en flux dans le navigateur. Cela ne veut pas dire qu’un hôte distant a reçu 5 Go de texte en clair.
La page FastPwd pour chiffrer un fichier suit cette frontière : AES-256-GCM dans Web Crypto ; la phrase secrète passe par PBKDF2-HMAC-SHA256, 100 000 itérations, un sel de 16 octets et une clé de 256 bits ; les blocs par défaut font 1 Mo, chacun avec un IV de 12 octets, le texte chiffré et une étiquette de 16 octets ; un fichier jusqu’à 5 Go ; sortie .lock / .enc avec la magie CSLK. Tous les outils sont prêts à l’emploi — aucun compte, aucun coffre. Si vous oubliez la phrase secrète, elle ne peut pas être récupérée, parce qu’elle n’a jamais été envoyée. Une promesse n’est encore qu’une promesse. La liste ci-dessous inclut la partie de l’en-tête qui n’est pas chiffrée.
Ce que le chiffrement peut prouver, et ce que l’en-tête montre encore
La conclusion que le chiffrement local soutient est tout aussi étroite. L’écrire évite une lecture trop large. Elle peut soutenir : sur cette exécution, le contenu du fichier est devenu du texte chiffré authentifié, bloc par bloc ; sans la phrase secrète, le déchiffrement doit échouer ; si Network ne trouve pas le canari, le texte en clair et la phrase secrète n’ont pas quitté l’onglet comme données HTTP métier observées.
Elle ne peut pas soutenir : le cloud ne voit aucune métadonnée, une extension n’a pas lu le presse-papiers, la phrase secrète est assez forte, ou quelqu’un qui a le texte chiffré ne tentera jamais une attaque hors ligne. FastPwd Lock v1 stocke le nom d’origine et le MIME en clair dans l’en-tête, pour que le déchiffrement puisse restaurer le nom. Envoyez cni-verso.lock, ou laissez cni-verso.jpg dans l’en-tête, et Drive — ou quiconque ouvre un visualiseur hexadécimal — peut lire ces mots. Le chiffrement couvre les blocs de contenu, pas l’étiquette que le conteneur montre au monde.
| Ce que vous voyez | Ce que cela soutient | Ce que cela ne soutient pas |
|---|---|---|
| L’extraction ZIP demande un mot de passe | La couche contenu a un verrou | Le répertoire est caché ; l’algorithme est AES-GCM |
| Vous listez les noms sans extraire | Le répertoire ZIP est en clair (le défaut habituel) | Le contenu peut aussi être ouvert |
| Les propriétés indiquent ZipCrypto / Zip 2.0 | Chiffre par flot classique ; une attaque à clair connu s’applique | Un long mot de passe arrête un outil dédié |
| Drive affiche un « stockage chiffré » | Un chiffrement en transit ou au repos est probable | Le prestataire n’a pas de clés et ne voit pas l’original |
Cet appareil a téléchargé un .lock / .enc |
Le navigateur a produit un fichier de texte chiffré | Le nom d’origine dans l’en-tête est caché aussi |
| Network ne trouve pas le canari | Ces requêtes n’ont pas emporté ces champs | Les extensions, le presse-papiers et la version suivante sont propres |
Contrôler maintenant : Network, l’en-tête et le hors ligne
Les slogans ne sont pas des preuves. Préparez un petit fichier jetable. Mettez canary-fp-20260904-zip-vs-gcm dans le corps et nommez-le canary-fp-20260904.txt. Utilisez une longue phrase secrète à usage unique. N’en réutilisez pas une vraie.
- Faites d’abord le témoin : empaquetez le même fichier dans un ZIP protégé. Ouvrez-le dans un extracteur sans saisir le mot de passe. Notez si les noms sont visibles, et si les propriétés indiquent ZipCrypto ou AES. C’est la plage qu’un mot de passe ZIP couvre réellement.
- Puis chiffrez en local dans le navigateur. Ouvrez Network dans DevTools, cochez Preserve log, et laissez le filtre sur All. Une fois le chiffrement terminé, collez le canari dans la recherche. Il ne doit figurer ni dans les lignes de requête, ni dans les corps, ni dans analytics.
- Ouvrez le
.locktéléchargé dans un visualiseur hexadécimal. Les quatre premiers octets doivent êtreCSLK(43 53 4C 4B). Plus loin, vous devez voir le sel, la taille de bloc, et le nom d’origine que vous avez laissé. La zone de contenu ne doit plus montrer cette phrase canari en clair. - Après le chargement de la page, passez Network en Offline ou coupez le réseau système, puis chiffrez un autre petit fichier jetable. Si un
.lockse télécharge encore, ce chiffrement/déchiffrement n’a pas eu besoin d’une API en direct. Le hors ligne doit passer ; une fois reconnecté, cherchez à nouveau le canari.
N’envoyez pas la phrase secrète sur le même canal que le texte chiffré. Placez le .lock dans Drive ; envoyez la phrase secrète via Burn-Link : ce navigateur chiffre en AES-256-GCM, le serveur ne stocke que le texte chiffré, et la clé se place dans le fragment # du lien, sous la forme s.html?id={id}#{key}. Déposer l’adresse de brûlage complète dans le même dossier Drive que le texte chiffré, c’est coller la clé sur la boîte.
Renommez la source avec un nom sans signification avant de chiffrer. L’en-tête écrit ce nom tel quel ; l’extension .lock / .enc apparaît aussi dans la liste Drive. Cela ne fait que réduire « le nom lui-même a fuité ». Ce n’est pas de la stéganographie.
Trois cas qui ont l’air chiffrés et ne bloquent pas ce que vous croyez
Premier cas, « chiffrer et zipper » sur un site. Certains clouds empaquettent après la fin de l’envoi, ou enveloppent un partage avec un code d’extraction. Ce code arrête ceux qui ne cliqueront pas sur le lien. Il n’arrête pas un serveur qui a déjà stocké l’original. Le contrôle : le chiffrement a-t-il eu lieu avant le choix du fichier, ou après la fin de la barre de progression ? Le second cas n’est pas de l’AES-GCM local.
Deuxième cas, un mot de passe d’ouverture Office ou PDF. Cela protège le flux d’ouverture du lecteur correspondant. Le format de fichier contient encore beaucoup de champs structurés ; l’aperçu Drive, la recherche plein texte et les services de conversion contournent souvent « demander un mot de passe à l’ouverture ». Ne le traitez pas comme un chiffrement authentifié du fichier entier.
Troisième cas, renommer l’extension. Changer .xlsx en .bin avant l’envoi n’arrête ni le téléversement instantané ni certains scanners, qui travaillent encore à partir d’un hachage de contenu ; la magie de l’en-tête est toujours là. Une extension n’est pas de la cryptographie. Après un chiffrement local, ces octets magiques doivent disparaître de la zone de contenu. Si un dump hexadécimal montre encore PK, %PDF ou un marqueur xlsx en clair, cette exécution n’a pas passé.
Questions fréquentes
Si je mets un mot de passe AES-256 sur un ZIP, l’envoyer dans Drive reste-t-il risqué ?
La couche contenu est plus solide que ZipCrypto, mais les noms, dates et tailles du répertoire ZIP restent lisibles par défaut. Drive et quiconque a l’archive peuvent lister les fichiers. Ce n’est pas non plus de l’AES-256-GCM dans le navigateur : WinZip AES utilise un autre encapsulage, et PBKDF2 fait 1 000 itérations. Si vous voulez que le cloud ne voie que du texte chiffré, chiffrez d’abord tout le contenu en local, puis envoyez.
Si Drive affiche un chiffrement en transit et au repos, est-ce suffisant ?
C’est en général le chiffrement par défaut, avec des clés que le prestataire détient. TLS couvre le trajet ; le chiffrement au repos couvre un disque volé. Le prestataire, un opérateur qui a accès aux clés, et une réquisition légale peuvent encore retrouver vos octets d’origine. Pour que « Google ne peut pas déchiffrer ceci » soit un fait sur Google Drive, un administrateur Workspace doit activer le chiffrement côté client. Ce n’est pas le chemin par défaut quand un compte personnel glisse un fichier dans Mon Drive.
Après l’envoi d’un .lock FastPwd, le cloud peut-il encore voir le nom d’origine ?
Oui. Il voit l’extension, et il peut lire le nom d’origine et le MIME dans l’en-tête. Ce qui est chiffré, ce sont les blocs de contenu de 1 Mo — pas les métadonnées du conteneur. Renommez la source avec un nom sans signification avant de chiffrer. Ne placez pas la phrase secrète dans le même partage que le texte chiffré.
Quand je chiffre sur FastPwd, le fichier ou la phrase secrète sont-ils envoyés ?
Selon les notes produit, chiffrement et déchiffrement se terminent dans l’onglet courant via Web Crypto. Le fichier et la phrase secrète ne partent pas comme données métier et ne sont pas écrits dans analytics. Les statistiques de visite enregistrent des noms d’action, pas le fichier ni la phrase secrète. Cherchez un canari dans Network : il ne doit figurer ni dans les lignes de requête, ni dans les corps. Localhost n’envoie pas de statistiques de visite par défaut ; retestez sur le nom d’hôte en ligne pour coller davantage à un usage réel.
Passer le même fichier jetable dans un outil prêt à l’emploi
Si vous voulez une page qui écrit la frontière de calcul à découvert, ouvrez FastPwd pour chiffrer un fichier. Prêt à l’emploi ; sans inscription. Choisissez le fichier canari ci-dessus et une longue phrase secrète à usage unique. Si la phrase est jugée faible, la page demande confirmation avant de continuer. Téléchargez le .lock. Surveillez Network en même temps : vous devez voir des ressources statiques et éventuellement des statistiques de visite, pas le fichier d’origine ni la phrase secrète comme champs métier.
Vous pouvez générer la phrase secrète en local dans le générateur de mots de passe. Le mode aléatoire va de 6 à 128 caractères, 16 par défaut ; en dessous de 8, un avertissement indique une sécurité plus faible. La génération n’est pas envoyée non plus. Quand un collègue doit recevoir la phrase secrète, passez par Burn-Link. Ne la mettez pas dans un commentaire Drive. N’enfoncez pas un secret d’une ligne dans un .lock comme canal de transport — chiffrer un fichier sert à sauvegarder et à remettre un fichier entier, pas un secret qui appartient à une ligne de chat.
Retenez trois choses avant le prochain envoi. Premièrement, un mot de passe ZIP bloque l’extraction, pas le répertoire, et pas une attaque à clair connu sur ZipCrypto. Deuxièmement, le chiffrement cloud par défaut laisse en général les clés chez le prestataire. Troisièmement, l’AES-256-GCM local protège les blocs de contenu ; l’en-tête et l’extension peuvent encore fuiter, donc regardez Network et un dump hexadécimal vous-même. Une observation que vous pouvez répéter est celle qui mérite d’entrer dans vos propres notes de sauvegarde.
Pour aller plus loin
« Chiffrement local, rien n’est envoyé » n’est pas une preuve tant que vous n’avez pas cherché un canari dans Network — voir Vérifier que le chiffrement local n’envoie pas le texte en clair. Quand vous remettez une phrase secrète au destinataire sur un canal à part, voir pourquoi la partie après le dièse reste hors de HTTP par défaut dans Pourquoi un fragment d’URL peut porter une clé, et quand cette protection lâche. S’il faut aussi masquer des numéros de pièce d’identité dans un ticket avant qu’ils quittent cet appareil, voir Avant de coller un ticket ou un journal dans une IA, vérifier quels champs quittent cet appareil.