Compresser puis chiffrer ou vice-versa?
J'écris un système VPN qui chiffre (AES256) son trafic sur le réseau (Pourquoi écrire le mien alors qu'il y en a déjà 1 000 001? Eh bien, le mien est spécial pour une tâche spécifique qui ne convient à aucun autre).
En gros, je veux dépasser votre réflexion pour être sûr de le faire dans le bon ordre.
Pour le moment, les paquets sont juste cryptés avant d'être envoyés, mais je veux leur ajouter un certain niveau de compression pour optimiser un peu le transfert des données. Pas de compression importante - Je ne veux pas utiliser le processeur au maximum tout le temps, mais je veux m'assurer que la compression sera aussi efficace que possible.
Donc, ma pensée est la suivante: je devrais compresser les paquets avant le chiffrement , car un paquet non chiffré compresse mieux qu'un paquet chiffré? Ou l'inverse?
Je vais probablement utiliser zlib pour la compression.
En savoir plus sur le blog du superutilisateur .
Si le cryptage est effectué correctement , le résultat est essentiellement une donnée aléatoire. La plupart des schémas de compression fonctionnent en trouvant des modèles dans vos données qui peuvent en quelque sorte être factorisés, et grâce au cryptage, il n’y en a plus; les données sont complètement incompressibles.
Compressez avant de chiffrer.
Compresser avant le cryptage. Les données compressées peuvent varier considérablement en cas de modifications mineures des données source, rendant ainsi très difficile la réalisation d'une analyse cryptographique différentielle.
En outre, comme le fait remarquer M. Alpha, si vous chiffrez d'abord, le résultat est très difficile à compresser.
Même si cela dépend du cas d'utilisation spécifique, je conseillerais Encrypt-then-Compress. Sinon, un attaquant pourrait divulguer des informations à partir du nombre de blocs chiffrés.
Nous supposons qu'un utilisateur envoyant un message au serveur et un attaquant avec la possibilité d'ajouter du texte au message de l'utilisateur avant l'envoi (via JavaScript, par exemple). L'utilisateur veut envoyer des données sensibles au serveur et l'attaquant veut récupérer ces données. Il peut donc essayer d’ajouter différents messages aux données que l’utilisateur envoie au serveur. Ensuite, l'utilisateur compresse son message et le texte ajouté par l'attaquant. Nous supposons une compression DEFLATE LZ77 afin que la fonction remplace les mêmes informations par un pointeur sur la première apparence. Donc, si l'attaquant peut reproduire le texte en clair du trou, la fonction de compression réduit la taille du texte brut à la taille d'origine et à un pointeur. Et après le cryptage, l’attaquant peut compter le nombre de blocs de chiffrement, ainsi il peut voir si les données ajoutées sont identiques à celles que l’utilisateur a envoyées au serveur. Même si cette affaire semble un peu construite, il s'agit d'un grave problème de sécurité dans TLS. Cette idée est utilisée par une attaque appelée CRIME pour divulguer des cookies dans une connexion TLS afin de voler des sessions.
source: http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf
Mon point de vue est que lorsque vous compressez un message, vous le projetez dans une dimension inférieure et ainsi, il y a moins de bits, ce qui signifie que le message compressé (en supposant une compression sans perte) contient la même information en moins de bits (ceux que vous avez supprimés étaient redondants! ) Ainsi, vous avez plus d’informations par bit et par conséquent plus d’entropie par bit, mais vous obtenez la même entropie totale que lorsque vous aviez le message non compressé. Maintenant, l’aléatoire est une autre affaire et c’est là que les modèles en compression peuvent jeter une clé à molette.
Compression avant le cryptage, comme cela a été souligné précédemment. La compression recherche la structure qu'il peut compresser. Le cryptage brouille les données afin d'éviter la détection de la structure. En compressant d'abord, vous aurez beaucoup plus de chances d'avoir un fichier plus petit et donc moins de charge à transférer. Le chiffrement remplira son rôle, qu'il soit compressé ou non et, comme encore une fois, il sera probablement plus difficile d'effectuer une analyse cryptographique différentielle sur un fichier compressé.
La compression doit être effectuée avant le cryptage. un utilisateur ne veut pas passer son temps à attendre le transfert des données, mais il a besoin que cela soit fait immédiatement sans perdre de temps.
La compression réduit l'entropie des informations. La compression maximale rend l'entropie minimale. Pour des données parfaitement cryptées (bruit), l’entropie maximale et minimale est identique.