Lors de la compression et du chiffrement, dois-je d'abord compresser ou chiffrer d'abord?
Si je devais crypter un fichier AES, puis le compresser ZLIB, la compression serait-elle moins efficace que si je commençais par compresser puis chiffrer?
En d'autres termes, dois-je d'abord compresser ou chiffrer d'abord, ou est-ce important?
Compressez d'abord. Une fois le fichier crypté, vous générerez un flux de données aléatoires, qui ne sera pas compressible. Le processus de compression dépend de la recherche de motifs compressibles dans les données.
La compression avant le chiffrement est certainement plus efficace en termes d'espace mais en même temps moins sécurisée. C'est pourquoi je ne serais pas d'accord avec d'autres réponses.
La plupart des algorithmes de compression utilisent des en-têtes de fichier "magiques" et pourraient être utilisés pour des attaques statistiques.
Par exemple, il y a attaque CRIME SSL/TLS .
Si votre algorithme de chiffrement est bon (et AES, avec un mode de chaînage approprié, est bon), aucun compresseur ne pourra réduire le texte chiffré. Ou, si vous préférez l'inverse: si vous réussissez à compresser du texte chiffré, il est grand temps de remettre en question la qualité de l'algorithme de chiffrement…
En effet, la sortie d'un système de cryptage ne doit pas être distinguée de données purement aléatoires, même par un attaquant déterminé. Un compresseur n'est pas un attaquant malveillant, mais il fonctionne en essayant de trouver des modèles non aléatoires qu'il peut représenter avec moins de bits. Le compresseur ne devrait pas être en mesure de trouver un tel modèle dans du texte crypté.
Vous devez donc d'abord compresser les données, puis crypter le résultat, et non l'inverse. C'est ce qui se fait, par exemple, dans le format OpenPGP .
Compressez d'abord. Si vous cryptez, vos données se transforment (essentiellement) en un flux de bits aléatoires. Les bits aléatoires sont incompressibles car la compression recherche des modèles dans les données et un flux aléatoire, par définition, n'a pas de modèles.
Bien sûr, cela compte. Il est généralement préférable de compresser d'abord, puis de chiffrer.
ZLib utilise codage Huffman et compression LZ77 . L'arbre Huffman sera plus équilibré et optimal s'il est exécuté sur du texte brut par exemple et donc le taux de compression sera meilleur.
Le chiffrement peut suivre après la compression même si le résultat de la compression semble être "chiffré" mais peut facilement être détecté comme étant compressé car le fichier commence généralement par PK.
ZLib ne fournit pas de cryptage natif. C'est pourquoi j'ai implémenté ZeusProtection . Le code source est également disponible sur github .
il est vrai que le compresseur ne fonctionne que sur des ensembles de données qui ont des modèles bien définis, mais il est exploratoire de crypter d'abord les données qui produisent des modèles non aléatoires bien définis qui peuvent être traités par le compresseur avec moins de complexité temporelle.
D'un point de vue pratique, je pense que vous devriez d'abord compresser simplement parce que de nombreux fichiers sont pré-compressés. Par exemple, l'encodage vidéo implique généralement une forte compression. Si vous cryptez ce fichier vidéo puis le compressez, il a maintenant été compressé deux fois. Non seulement la seconde compression obtiendra un taux de compression lamentable, mais la compression à nouveau prendra beaucoup de ressources pour compresser des fichiers ou des flux volumineux. Comme Thomas Pornin et Ferruccio l'ont indiqué, la compression des fichiers cryptés peut de toute façon avoir peu d'effet en raison du caractère aléatoire des fichiers cryptés.
Je pense que la meilleure et la plus simple politique peut être de compresser les fichiers uniquement au besoin (en utilisant une liste blanche ou une liste noire), puis de les chiffrer malgré tout.