Vous saisissez un mot de passe dans un gestionnaire d’archives et, un instant plus tard, un fichier s’ouvre. Entre ces deux événements se trouve une courte chaîne d’étapes qui décide de la solidité de la protection et de la façon dont un programme distingue un bon mot de passe d’un mauvais. Cette chaîne, c’est le fonctionnement même de la protection par mot de passe des ZIP, et la suivre du mot de passe saisi jusqu’au fichier déverrouillé montre exactement d’où vient sa solidité.

Un mot de passe ZIP ne chiffre jamais rien directement. L’outil le transforme en matériel de clé, soit en initialisant les trois clés internes de ZipCrypto, soit en exécutant PBKDF2 pour WinZip AES. Cette clé chiffre les octets compressés de chaque fichier. De petites valeurs stockées, un octet de contrôle ou une valeur de vérification, permettent de rejeter à faible coût les mauvais mots de passe avant qu’une étape de confirmation n’accepte le bon.

Du mot de passe à la clé

Les deux schémas partent de la même entrée, les octets de votre mot de passe (UTF-8 dans les outils modernes). C’est le traitement appliqué ensuite à ces octets qui sépare les deux schémas.

ZipCrypto : trois clés, sans étirement

ZipCrypto, le schéma traditionnel de PKWARE, conserve tout son état dans trois clés de 32 bits. Elles partent de constantes fixes, et chaque octet du mot de passe les met à jour à tour de rôle : la première clé passe par une mise à jour de table CRC-32 avec l’octet du mot de passe, la deuxième absorbe l’octet bas de la première puis est multipliée par une constante, et la troisième passe par une mise à jour CRC-32 avec l’octet haut de la deuxième. C’est toute la dérivation de clé.

Il n’y a ni sel ni étirement. Deux archives verrouillées avec le même mot de passe partent d’un état de clés identique, et tester un candidat ne coûte qu’une poignée d’opérations arithmétiques. Les faiblesses à texte clair connu qui découlent de cette conception sont détaillées dans l’explication de ZipCrypto.

WinZip AES : PBKDF2 avec un sel par entrée

WinZip AES traite le mot de passe comme l’entrée d’une fonction volontairement lente. L’outil lit d’abord un octet de robustesse dans le champ additionnel de l’entrée : 1 signifie AES-128, 2 signifie AES-192 et 3 signifie AES-256. Cet octet fixe la longueur de la clé à 16, 24 ou 32 octets et celle du sel à 8, 12 ou 16 octets.

L’outil exécute ensuite PBKDF2-HMAC-SHA1 pendant 1000 itérations sur le mot de passe et un sel aléatoire stocké avec cette entrée. Le résultat est découpé en trois parties : la clé de chiffrement AES, une clé d’authentification distincte de même longueur et une valeur de vérification du mot de passe de 2 octets. Comme chaque entrée porte son propre sel, le même mot de passe donne des clés différentes dans des entrées différentes, et les tables précalculées ne servent à rien. Les 1000 itérations se répètent pour chaque bloc de 20 octets de clé dérivée, si bien qu’un seul essai coûte, et c’est voulu, entre deux mille calculs HMAC-SHA1 (AES-128) et quatre mille (AES-256), trois mille pour AES-192. La page sur WinZip AES couvre le chiffrement en mode CTR lui-même et les variantes AE-1 et AE-2.

Comment un outil sait que le mot de passe est le bon

Déchiffrer et décompresser un fichier entier pour chaque candidat serait du gaspillage : les deux formats stockent donc une petite valeur qu’un lecteur peut vérifier en premier. Ce contrôle est un filtre, pas une preuve. Un candidat qui le passe subit ensuite un test de confirmation complet. Une seule entrée suffit ; ZipRecover privilégie la plus petite entrée chiffrée assez grande pour confirmer un mot de passe de façon décisive (parmi les entrées d’au plus 256 Mo compressés), ce qui garde chaque confirmation peu coûteuse. Si toutes les entrées testables sont des fichiers ZipCrypto de moins de 4 octets, le résultat indique que le mot de passe n’a réussi qu’une vérification rapide. Si la seule entrée testable utilise une méthode de compression autre que Store ou Deflate, l’outil ne peut comparer que la longueur déchiffrée, que le bon mot de passe ne passe généralement pas non plus, et une recherche se termine alors en général sans correspondance. Si toutes les entrées chiffrées dépassent 256 Mo compressés, l’outil affiche une erreur au lieu de chercher.

Schéma Premier contrôle rapide Confirmation
ZipCrypto Déchiffrer l’en-tête de chiffrement de 12 octets et comparer son dernier octet à un octet de contrôle connu (l’octet haut du CRC-32 stocké, ou celui de l’heure de modification lorsqu’un descripteur de données est utilisé) : un filtre d’environ 1 sur 256 Déchiffrer le reste de l’entrée, la décompresser et comparer le CRC-32 et la taille du résultat aux valeurs du répertoire central
WinZip AES Comparer la valeur de vérification de 2 octets produite par PBKDF2 à celle stockée juste après le sel : un filtre d’environ 1 sur 65 536 Recalculer HMAC-SHA1 sur le texte chiffré avec la clé d’authentification et comparer les 10 premiers octets au code d’authentification stocké

Les deux filtres ne se valent pas. Environ 1 mauvais mot de passe sur 256 passe l’octet de contrôle de ZipCrypto, et c’est l’étape de déchiffrement et de CRC qui doit l’attraper ; cette étape reste une somme de contrôle et non une preuve cryptographique, même si un mauvais mot de passe qui se décompresse proprement avec la bonne taille et le bon CRC-32 est extrêmement improbable sur des fichiers réels. Pour AES, environ 1 mauvais mot de passe sur 65 536 survit à la valeur de vérification, et l’étape HMAC-SHA1 qui suit est cryptographiquement définitive : un mot de passe AES confirmé n’est jamais un faux positif.

Observez où tombe le coût. Dans ZipCrypto, les deux étapes sont bon marché. Dans AES, la partie coûteuse, PBKDF2, s’exécute avant le filtre, si bien que le filtre n’économise que le HMAC, et le schéma peut se permettre de rendre chaque essai lent.

Ce que cela signifie pour un mot de passe oublié

Aucune étape de cette chaîne ne peut être sautée. On ne peut pas demander son mot de passe à une archive ; un outil ne peut que proposer des candidats et faire passer chacun par les étapes ci-dessus. La récupération dépend donc de la taille de l’espace à explorer et de la vitesse à laquelle chaque candidat peut être testé.

Un calcul illustratif donne l’échelle. Prenez un mot de passe de 12 caractères composé de majuscules, de minuscules et de chiffres : 62^12, soit environ 3,2 × 10^21 candidats. Au débit d’un seul cœur pour AES-256 que le site a mesuré avec son script de preuve, environ 640 essais par seconde, épuiser cet espace prend 3,2 × 10^21 ÷ 640, soit environ 5 × 10^18 secondes, ou à peu près 1,6 × 10^11 ans (160 milliards d’années). Même au débit ZipCrypto mesuré de la même façon, environ 240 000 essais par seconde, le même espace demande de l’ordre de 4 × 10^8 ans. Ces deux chiffres sont modélisés à partir de ces débits mesurés, pas mesurés sur un fichier précis, et ajouter des cœurs ne les divise que linéairement.

Réduisez maintenant l’espace avec ce dont vous vous souvenez. Si vous savez que le mot de passe comptait six lettres minuscules, cela fait 26^6, environ 309 millions de candidats, que les mêmes 640 par seconde couvrent en à peu près 5,6 jours sur un cœur, ou environ 17 heures réparties sur huit threads de travail (là encore, à titre illustratif). Un préfixe connu, une longueur mémorisée ou une liste de mots personnelle réduisent la recherche bien plus qu’un matériel plus rapide. Le guide sur la durée de la récupération d’un mot de passe ZIP détaille ces débits.

Tout ce qui précède concerne le contenu de chaque entrée. Les noms, tailles et horodatages du répertoire central restent lisibles dans un ZIP chiffré standard ; le guide sur ce que protège un fichier ZIP chiffré couvre cette vue du conteneur et la façon de reconnaître le schéma utilisé.

Si l’archive est la vôtre et que le mot de passe est perdu, notez d’abord ce dont vous vous souvenez de sa forme, puis lancez une récupération privée de votre mot de passe ZIP dans le navigateur. L’outil lit l’octet de robustesse, privilégie la plus petite entrée chiffrée assez grande pour confirmer un mot de passe de façon décisive (parmi les entrées d’au plus 256 Mo compressés) et applique exactement la chaîne filtre puis confirmation décrite ici, uniquement sur votre appareil.

Sources