Ce que le chiffrement par défaut, les noms de fichiers et les entrées non chiffrées laissent encore après l’envoi d’un ZIP protégé par mot de passe

Un mot de passe n’est pas un cadenas sur toute l’archive

Un ZIP protégé par mot de passe se laisse facilement prendre pour un coffre : qui tient le fichier ne voit rien sans la clé. Le format est plus morcelé. Un ZIP, c’est d’abord un répertoire, puis une liste de fichiers. Le drapeau de chiffrement est accroché à l’en-tête local et à l’entrée du répertoire central de chaque fichier. Il n’est pas accroché à « le fichier .zip tout entier ». Poser un mot de passe veut seulement dire qu’au moins un flux compressé a été enveloppé par un algorithme. Cela ne veut pas dire que le répertoire est illisible, ni que chaque entrée a utilisé le même algorithme ou la même phrase.

Bulletins de paie, scans de pièce d’identité, clés SSH privées, dumps de base et tableaux clients non masqués n’ont rien à faire en indices clairs hors du dossier où vous travaillez. La question n’est pas « cet archiveur est-il malin ». C’est « ce paquet a-t-il remis un nom en clair, une entrée ouverte, ou un flux faiblement chiffré qui aurait dû rester sur ce disque ». La note précédente traitait une remise voisine : un fichier non chiffré déposé dans un Drive peut encore être ouvert par le fournisseur, le client de synchro et un hash de contenu. Zipper d’abord avec un mot de passe ne fait que déplacer la question : ce n’est plus « le cloud voit-il le fichier », c’est « quelle couche ce conteneur a vraiment verrouillée ».

Cette note s’en tient à l’APPNOTE.TXT 6.3.10 de PKWARE (1^er novembre 2022), aux spécifications AES WinZip AE-1 / AE-2 et à la description AES-256 du format 7z par 7-Zip, parce que ces textes écrivent les couches dans une langue que vous pouvez recouper avec un listage local. Une politique d’entreprise, une page web « chiffrer un zip » et une vieille interface peuvent ajouter une autre couche. Changez d’outil, relisez les options de chiffrement de cette version et regardez Method à nouveau. Ne collez pas les phrases ZipCrypto ci-dessous sur une archive qui a déjà choisi AES-256 ou coché « Chiffrer les noms de fichiers ».

ZipCrypto, extension AES et chiffrement des noms : trois couches distinctes

Entendre « le ZIP est-il chiffré » comme une question oui/non fait tomber au moins trois couches. La première est le chiffrement PKWARE classique — celui que les interfaces appellent souvent ZipCrypto ou Zip 2.0. La section 6 de l’APPNOTE garde l’objet étroit : PKZIP chiffre le flux de données déjà compressé. Chaque fichier chiffré commence par un en-tête de 12 octets. Trois clés de 32 bits partent de la phrase, puis se mettent à jour avec le même CRC-32 que le ZIP utilise déjà. L’extension reste .zip. L’Explorateur ou un vieux décompresseur affiche souvent une invite. La compatibilité est bonne. La robustesse est une autre question.

La deuxième couche est l’AES ajouté plus tard dans le même conteneur ZIP. WinZip laisse la structure de base et ajoute une pièce : la méthode de compression devient 99 en décimal, et l’en-tête local comme le répertoire central portent un champ extra de 11 octets 0x9901 dont l’identifiant fabricant est le ASCII AE. Les octets de force 0x01 / 0x02 / 0x03 correspondent à des clés de 128, 192 et 256 bits. La vraie méthode (le 8 de Deflate, par exemple) passe dans ce champ extra. Un vieux logiciel qui ne comprend pas l’AES signale en général « méthode de compression 99 non prise en charge », au lieu de traiter le chiffré comme du clair. Cette couche protège le contenu. Par défaut, elle ne réécrit pas les noms du répertoire central en chiffré.

La troisième couche, c’est « couvrir aussi le répertoire ». Le Strong Encryption du ZIP écrit le chiffrement du répertoire central comme une option et demande des drapeaux general purpose supplémentaires, notamment les bits 6 et 13. ZipCrypto classique n’a pas cette couche. Le format 7z prend un autre chemin. La page format de 7-Zip indique AES-256, une dérivation de clé à partir de la phrase via une fonction fondée sur SHA-256, et un grand nombre d’itérations pour renchérir une recherche exhaustive. L’option en ligne de commande -mhe=on chiffre les noms de fichiers. Sans elle, un listage peut encore montrer les noms même si le contenu est en AES.

ZipCrypto : la spécification le juge elle-même faible

Le chiffrement classique n’est pas une rumeur du type « on dit que c’est faible ». Le propriétaire du format l’a déjà rétrogradé. L’APPNOTE 6.0.1 écrit que cette forme est considered weak by today’s standards et la recommande seulement pour un besoin de sécurité faible, ou pour rester compatible avec d’anciens programmes ZIP. La même section dessine le squelette : les clés partent des entiers 32 bits 305419896, 591751049 et 878082192 ; update_keys applique un CRC-32 à chaque octet de la phrase ; un en-tête de 12 octets en tête de la zone de données continue de mélanger les clés ; le ou les deux derniers octets de l’en-tête sont comparés aux bits de poids fort du CRC pour décider si la phrase « a l’air » correcte. C’est un chiffrement par flot. Ce n’est pas un mode de bloc authentifié comme AES-GCM.

La spécification dit aussi que l’en-tête de 12 octets existe pour « rendre inefficace une attaque en clair sur les données ». La recherche publique a pris un autre chemin. En 1994, Eli Biham et Paul C. Kocher ont publié A Known Plaintext Attack on the PKZIP Stream Cipher : un morceau de clair connu suffit à retrouver l’état interne. La note de 2002 de Michael Stay, ZIP Attacks with Reduced Known Plaintext, a encore abaissé la quantité de clair nécessaire. Les archives portent souvent des préfixes prévisibles — %PDF, un en-tête Office fixe, une déclaration XML, une signature PNG — parce que ce sont des formats de fichier, pas des secrets. Les étapes d’attaque sortent du périmètre de cette note. Le point qui entre dans une conclusion : la faiblesse est l’algorithme, pas « votre mot de passe n’a que six caractères ». Allonger la phrase ne réécrit pas « la spécification juge le chiffrement classique faible, et une ligne de recherche en clair connu existe ».

La compatibilité explique pourquoi la méthode est encore là. L’Explorateur de fichiers Windows crée et ouvre des ZIP ordinaires, mais n’a pas d’interface native « mettre un mot de passe sur ce ZIP ». Un conseiller indépendant sur Microsoft Q&A a écrit qu’il faut un outil tiers comme 7-Zip pour poser un mot de passe, et que l’Explorateur peut encore afficher une invite sur les archives ZipCrypto produites par ces outils. Beaucoup de logiciels laissent donc ZipCrypto par défaut, pour que l’autre côté double-clique. Vous gagnez « ils n’ont rien à installer ». Vous payez le chiffrement faible que la spécification admet déjà. 7-Zip peut écrire un ZIP en AES-256 à la place. Après ce changement, un extracteur système qui ne connaît que ZipCrypto peut refuser d’ouvrir le fichier. C’est un arbitrage entre compatibilité et robustesse, pas « les deux menus disent chiffrement, donc c’est la même chose ».

Noms, CRC et entrées non chiffrées : ce qui n’entre pas dans le flux reste en clair

Même après le passage du contenu en AES, un ZIP reste, par défaut, un conteneur que l’on peut lister. FileName dans l’en-tête local et le répertoire central est un champ en clair. Le bit 0 general purpose signifie seulement que le flux de cette entrée est chiffré. Le bit 11 signifie que le nom est en UTF-8. Il ne signifie pas que le nom est chiffré. En 2004, l’analyse de Tadayoshi Kohno sur le schéma WinZip écrivait trois faits de format en langage simple : les métadonnées des fichiers chiffrés fuient, les noms ne sont pas authentifiés, et une même archive peut tenir à la fois des fichiers chiffrés et non chiffrés. Ce sont des formes autorisées du conteneur, pas des bugs d’implémentation.

La note AES de WinZip elle-même écrit les archives mixtes comme une permission formelle. Rien n’exige que chaque fichier d’un ZIP soit chiffré, ni que les fichiers chiffrés partagent une méthode ou une phrase. Une archive peut combiner des fichiers non chiffrés avec Zip 2.0, AES-128, AES-192 et AES-256 dans n’importe quel mélange. Les entrées de dossiers sont même recommandées non chiffrées, pour gagner de la place. Résultat concret : vous mettez paie-2026-09.xlsx et readme.txt dans le même paquet, et seule la feuille peut demander un mot de passe. La note et les noms de répertoire se lisent par quiconque tient le fichier. Destinataires, passerelles mail, aperçus Drive et clients de synchro voient souvent cette liste d’abord — pas les cellules après une extraction réussie.

Les en-têtes en clair portent aussi tailles et sommes de contrôle. WinZip écrit que AE-1 stocke le CRC du contenu non chiffré dans l’en-tête ZIP, tandis que AE-2 met le CRC à 0 et s’appuie sur un code d’authentification de 10 octets pour l’intégrité. La FAQ donne la raison : pour un fichier de quatre octets ou moins, le CRC lui-même peut aider à inférer l’original, quel que soit le chiffrement. À partir de WinZip 11, la plupart des fichiers reviennent à AE-1 pour un contrôle d’intégrité supplémentaire, mais les fichiers dont la taille non compressée est inférieure à 20 octets, et les flux BZIP2 qui portent déjà leur propre contrôle, restent en AE-2 et ne stockent pas de CRC. La dérivation de clé est PBKDF2 (RFC 2898) avec 1 000 itérations ; la fonction pseudo-aléatoire est HMAC-SHA1. La spécification note aussi que HMAC-SHA1 sort 160 bits, donc l’espace de recherche effectif d’un AES 192 ou 256 bits ne se lit pas comme la longueur théorique de la clé. Vous n’avez pas besoin d’un « crack » pour vérifier ces chiffres. Ils sont déjà dans la spécification publique.

Vérifier un ZIP protégé sans extraire le clair

Un slogan « j’ai mis un mot de passe, donc c’est sûr » ne se prouve pas tout seul. Découpez le contrôle en étapes que vous pouvez finir sur cette machine. Chaque étape répond à une question. N’utilisez pas une vraie fiche de paie, un certificat ou une clé privée pour l’expérience.

1. Écrivez un texte canari dont le nom a volontairement l’air d’un document métier, par exemple canary-paie-20260905.txt. S’il vous faut une phrase aléatoire, tirez 6 à 128 caractères dans le générateur de mot de passe (16 par défaut ; sous 8, un avertissement de force faible s’affiche). Traitez cette chaîne seulement comme mot de passe d’archive, pas comme un nouveau mot de passe de connexion.
2. Construisez un ZIP comme vous envoyez d’habitude : certains outils partent sur ZipCrypto ; d’autres exigent de choisir AES-256. Ne renommez pas le fichier pour « cacher » le sujet. Construisez une deuxième archive 7z, une fois avec le chiffrement des noms, une fois sans, pour comparer.
3. Ne saisissez pas encore la phrase. Ouvrez le ZIP dans 7-Zip, ou lancez 7z l -slt canary.zip dans un terminal. Voyez si la liste montre déjà canary-paie-20260905.txt. Puis trouvez la ligne Method = : ZipCrypto est le chiffrement classique ; AES-256 est l’AES de contenu. Vous lisez les deux sans extraire le corps, donc ils ne sont pas derrière « il faut d’abord taper le mot de passe ».
4. Listez l’archive 7z de la même façon. Sans chiffrement des noms, le nom apparaît souvent encore. Avec -mhe=on, le nom canari ne devrait pas apparaître tant que vous n’avez pas saisi la phrase. C’est un contrôle de la troisième couche, pas une affirmation que « le 7z est automatiquement plus mystérieux que le ZIP ». La différence, c’est si l’en-tête du répertoire est couvert.
5. Déposez l’archive canari dans le Drive ou le brouillon mail que vous utilisez vraiment (ne l’envoyez à personne). Voyez si l’aperçu ou l’interface web liste les noms internes. La note précédente couvrait l’envoi instantané et l’aperçu sur un fichier non chiffré ; ici, même si le contenu est verrouillé, les noms de répertoire peuvent encore être indexés. Quand vous avez fini, supprimez l’archive canari et le fichier source, et regardez la corbeille.

Savoir si cet onglet a remis du clair à un serveur est une autre question, traitée dans Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Un archiveur doit presque toujours lire l’original sur cette machine pour le compactage. Cette note demande ce qui reste après le compactage, hors du flux chiffré. Si le nom canari apparaît dans 7z l -slt ou dans un aperçu Drive avant que vous tapiez un mot de passe, la frontière de confiance est plus large que « l’autre n’a pas le mot de passe ». Si Method est encore ZipCrypto, vous avez acheté de la compatibilité, pas un chiffrement fort au sens de la spécification.

Séparer le chiffré d’un fichier entier du mot de passe d’archive

Si ce que vous voulez, c’est « transformer ce fichier en chiffré sur cet appareil, puis décider si l’e-mail ou un Drive le transporte », vous n’avez pas à vous inscrire, et vous ne remettez pas le fichier à MakePwd. Ouvrez Chiffrer un fichier. L’onglet chiffre par blocs en AES-256-GCM et vous laisse télécharger .lock ou .enc. La phrase secrète est étirée avec PBKDF2-HMAC-SHA256 et 100 000 itérations ; chaque fichier a son propre sel. Un fichier peut aller jusqu’à 5 Go. Le fichier, la phrase secrète et le clair ne partent pas comme données métier. Tous les outils s’ouvrent sans compte, et il n’y a pas de coffre de mots de passe qui garde cette phrase pour vous.

Chiffrer un fichier répond à « ces octets sont-ils devenus du chiffré avant de quitter le navigateur ». Cela ne répond pas à « un ZIP verrouille-t-il les noms par défaut ». Vous choisissez le nom du téléchargement, donc vous n’êtes pas obligé d’envoyer un bulletins-paie-2026.xlsx.zip qui annonce le sujet. L’en-tête .lock peut encore porter le nom d’origine ; s’il est sensible, renommez le fichier avant de chiffrer. Le chiffré peut voyager par un Drive ou un e-mail. Envoyez la phrase par un autre canal — par exemple un lien auto-destructible : la clé reste dans le fragment # de l’URL, elle n’entre pas dans HTTP, création et lecture sont publiques, et le serveur ne stocke que du chiffré. Quand il vous faut une phrase aléatoire, tirez 6 à 128 caractères dans le générateur de mot de passe et copiez-la seulement sur cette page. Ce qu’un fournisseur peut encore voir après un envoi non chiffré, c’est la note précédente. Celle-ci ne trace qu’une ligne autour de ce qu’un ZIP protégé par mot de passe peut encore laisser derrière lui.

Questions fréquentes

Si un ZIP a un mot de passe, toute l’archive est-elle chiffrée ?

Non. L’APPNOTE de PKWARE place le drapeau de chiffrement sur le bit 0 general purpose de chaque fichier. Ce bit couvre le flux compressé de cette entrée, pas le conteneur. Les noms figurent dans l’en-tête local et le répertoire central. La note AES de WinZip précise qu’un même ZIP peut mélanger des entrées non chiffrées avec Zip 2.0, AES-128, AES-192 et AES-256, et que les mots de passe peuvent différer.

Quelle est la différence entre ZipCrypto et un ZIP AES-256 ?

ZipCrypto est le chiffrement PKWARE classique de la section 6 de l’APPNOTE : trois clés de 32 bits, un en-tête de 12 octets, et une mise à jour des clés par CRC-32. La spécification le juge faible selon les critères d’aujourd’hui et le réserve aux besoins peu sensibles ou aux vieux programmes ZIP. WinZip AES utilise le champ extra 0x9901, la méthode de compression 99, un sel, un vérificateur de mot de passe et un code d’authentification HMAC-SHA1. Les deux gardent l’extension .zip : il faut lire Method, pas le suffixe.

Peut-on voir la liste des fichiers sans le mot de passe ?

En général oui, pour un ZIP classique et pour une archive 7z sans chiffrement des noms. 7z l -slt de 7-Zip liste les noms et Method sans extraire le clair. Le format 7z peut chiffrer les noms avec -mhe=on ; c’est cette couche qui couvre l’en-tête du répertoire. L’Explorateur de fichiers Windows n’a pas d’interface native pour poser un mot de passe sur un ZIP.

Un ZIP à mot de passe, est-ce la même chose que Chiffrer un fichier sur MakePwd ?

Non. Le mot de passe d’archive répond à « quel chiffrement ZIP ce conteneur a utilisé ». Chiffrer un fichier chiffre le fichier entier dans cet onglet en AES-256-GCM, écrit .lock / .enc, limite un fichier à 5 Go, n’envoie ni le fichier ni la phrase secrète, et s’ouvre sans compte. Envoyez la phrase par un autre canal, par exemple le fragment # d’un lien auto-destructible.

Trois points à retenir avant la prochaine archive

Premier : « j’ai mis un mot de passe » veut seulement dire qu’au moins un flux a été enveloppé par un chiffrement ZIP. Cela ne veut pas dire que le répertoire est illisible, ni que chaque entrée est chiffrée. Deuxième : ZipCrypto (la spécification le juge faible ; une ligne de recherche en clair connu existe), WinZip AES (plus robuste sur le contenu ; les noms restent en clair par défaut) et le chiffrement des noms 7z sont trois frontières différentes. Une extension .zip ou .7z ne dit pas à quelle couche vous êtes. Troisième : contrôlez Method et les noms qui apparaissent avant la phrase avec un canari à usage unique et 7z l -slt. Ne faites pas ce contrôle sur un vrai tableau.

Si la question suivante est ce qu’un fournisseur peut encore voir après qu’un fichier non chiffré entre dans un Drive, lisez Ce qu’un fournisseur cloud, le client de synchro et le hash de contenu voient encore après l’envoi d’un fichier non chiffré. Quand l’étape de chiffrement elle-même doit prouver que le clair n’a pas quitté cet appareil, lisez Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Quand la phrase doit voyager à part et que vous ne voulez pas la mettre dans le corps d’un e-mail, lisez Pourquoi le fragment après # d’une URL convient pour une clé, et quand cette protection lâche. Cette note ne trace qu’une ligne que vous pouvez écrire dans une conclusion : après l’envoi d’un ZIP protégé par mot de passe, ce que le chiffrement par défaut, les noms de fichiers et les entrées non chiffrées peuvent encore laisser.