Si je devais crypter un fichier en AES, puis le compresser en ZLIB, la compression serait-elle moins efficace que si j'avais d'abord compressé puis crypté ?
En d'autres termes, dois-je compresser ou crypter en premier, ou est-ce important ?
Ce n'est pas vraiment aléatoire. C'est juste qu'aucun algorithme de compression ne sera plus capable de repérer le motif une fois qu'il aura été crypté.
C'est vrai. Ça a l'air aléatoire. Le processus est déterministe, donc avec les mêmes données et la même clé, vous obtiendrez le même résultat aléatoire.
En supposant que l'algorithme de cryptage prenne des mesures pour supprimer les motifs (comme l'utilisation d'un chiffrement par blocs en mode CBC avec un IV aléatoire), les données cryptées sont indiscernables des données aléatoires.
Si votre algorithme de cryptage est bon (et AES, avec un mode de chaînage approprié, est bon), alors aucun compresseur ne sera en mesure de réduire le texte crypté. Ou, si vous préférez l'inverse : si vous parvenez à compresser un texte crypté, alors il est grand temps de remettre en question la qualité de l'algorithme de cryptage...
En effet, le résultat d'un système de cryptage ne devrait pas pouvoir être distingué du hasard pur, 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 motif dans le texte crypté.
Vous devez donc commencer par compresser les données, puis chiffrer le résultat, et non l'inverse. C'est ce qui est fait, par exemple, dans le module Format OpenPGP .
Bien sûr que ça compte. Il est généralement préférable de compresser d'abord et de crypter ensuite.
ZLib utilise Codage de Huffman et compression LZ77 . L'arbre de Huffman sera plus équilibré et optimal s'il est réalisé sur du texte brut par exemple et le taux de compression sera donc meilleur.
Le cryptage peut suivre la compression même si le résultat de la compression semble être "crypté" mais peut facilement être détecté comme étant compressé car le fichier commence généralement par PK.
ZLib ne fournit pas de cryptage de façon native. C'est pourquoi j'ai implémenté ZeusProtection . Le code source est également disponible à l'adresse suivante github .
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Ce n'est pas du tout la même question. Cette question porte sur l'efficacité, l'autre sur la sécurité.
0 votes
J'ai l'impression que cette question n'a jamais reçu de réponse complète, car les réponses semblent toutes discuter de l'efficacité du point de vue de la "taille des données compressées" (ou du taux de compression, ou de ce que vous voulez appeler). Un autre aspect à prendre en compte est le temps total du processeur nécessaire pour traiter les données, et selon cette mesure, pour une charge utile compressible (c.-à-d. texte, et non binaire) de taille non triviale (c.-à-d. tout ce qui dépasse quelques Ko), il est plus efficace du point de vue du calcul de compresser puis de crypter (même par rapport au simple cryptage des données non compressées et à l'absence totale de compression).