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).

Fondamentalement, je veux dépasser ma pensée pour m'assurer que je le fais dans le bon ordre.

Pour le moment, les paquets sont simplement cryptés avant d'être envoyés, mais je souhaite leur ajouter un niveau de compression afin d'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 de les chiffrer, car un paquet non chiffré compressera mieux qu'un paquet chiffré? Ou l'inverse?

Je vais probablement utiliser zlib pour la compression.

Plus d'informations sur le blog du super utilisateur .

Si le cryptage est effectué correctement, le résultat est essentiellement des données aléatoires. 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 ses données ajoutées étaient 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 celle que vous aviez auparavant lorsque le message n’était pas compressé. Maintenant, l’aléatoire est un autre problème et c’est là que les modèles en compression peuvent jeter une clé à molette.

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.

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 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.