Afin d'envoyer un fichier en toute sécurité, je vais chiffrer/protéger par mot de passe un fichier Zip. ( Pourquoi je fais ça ). J'utilise macOS Sierra 10.12.6 et à travers mon recherche j'ai conclu que le cryptage d'un fichier Zip se fait de la manière suivante sur macOS,
Zip -e [newzip].Zip [myFile].[extension]
Cela fonctionne parfaitement, mais je voudrais m'assurer que l'algorithme/la méthode utilisée pour crypter le Zip est sécurisé. Malheureusement, je ne trouve aucune documentation sur l'algorithme/la méthode que la commande Zip
utilise pour chiffrer, que ce soit AES-256 bits, AES-128 bits ou quelque chose de complètement différent.
La page man
de Zip
ne sert à rien:
-e
--encrypt
Encrypt the contents of the Zip archive using a password which
is entered on the terminal in response to a Prompt (this will
not be echoed; if standard error is not a tty, Zip will exit
with an error). The password Prompt is repeated to save the
user from typing errors.
Veuillez inclure dans votre réponse l'algorithme utilisé, une source possible pour ces informations, et si ce n'est pas AES-256bit/AES-128bit, alors comment l'algorithme/méthode est sécurisé.
Il utilise le cryptage PKZIP 2.0 d'origine (diversement appelé cryptage "traditionnel" ou "hérité"), décrit dans la section 6 de la spécification du format de fichier .Zip . Il est basé sur l'utilisation de CRC32 pour mélanger le mot de passe, une graine aléatoire (espérons-le) et le fichier compressé. Il n'est pas considéré comme sûr; à tout le moins, il présente de sérieuses vulnérabilités aux attaques en texte clair connues (voir cette réponse crypto.se pour un résumé).
Ceci est basé sur: en regardant le code source d'Apple pour Zip . Le README.CR dit:
Le code de cryptage est une transcription directe de l'algorithme de Roger Schlafly, décrit par Phil Katz dans le fichier appnote.txt. Ce fichier est distribué avec le programme PKZIP (même dans la version sans capacité de chiffrement). Notez que le cryptage résistera probablement aux attaques d'amateurs si le mot de passe est bien choisi et suffisamment long (au moins 8 caractères) mais il ne résistera probablement pas aux attaques d'experts. Paul Kocher a mis à disposition des informations concernant une attaque en texte brut connue pour le schéma de cryptage PKWARE; voir http://www.cryptography.com/ pour plus de détails.) Les mots de passe courts composés uniquement de lettres minuscules peuvent être récupérés en quelques heures sur n'importe quel poste de travail. Mais pour la cryptographie décontractée conçue pour empêcher votre mère de lire votre courrier, c'est OK.
Notez que le fichier dit a été mis à jour pour la dernière fois en 2008, donc quand il parle de récupération de mot de passe "en quelques heures sur n'importe quel poste de travail", il s'agit de matériel vieux de dix ans. Je suis légèrement confus quant à la version de Zip Apple utilise réellement. README.CR semble indiquer que c'est la v2.31, mais WHATSNEW répertorie les nouvelles fonctionnalités de Zip v3.0 beta (et dit AES est prévu pour la v3.1). En tout cas, c'est assez vieux.
Comme support supplémentaire, le fichier crypto.c (bien qu'un peu difficile à suivre) utilise clairement CRC32 pour les processus de cryptage/décryptage, et les seules mentions d'AES se trouvent dans plusieurs fichiers qui indiquent qu'il est prévu pour une version ultérieure.
Oh, et j'ai également essayé de créer un fichier crypté avec lui, puis j'ai regardé un vidage hexadécimal. Il ne contient pas 0x0017, qui est l'ID d'en-tête pour un "en-tête de cryptage fort". Il contient 12 octets supplémentaires de données de départ (faisant partie du format "hérité") avec chaque fichier. Cela correspond donc au code source et au fichier README.
Résumé: ne l'utilisez pas. Je rechercherais des utilitaires Zip tiers qui prennent en charge un cryptage plus moderne, mais je ne connais pas suffisamment l'un d'eux pour faire des recommandations.