Compresser puis chiffrer ou vice-versa?

88

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 .

Majenko
la source
4
Ecrire comme "programmation"? Serait mieux adapté pour Stack Overflow alors.
Suma
4
Si je posais des questions sur la programmation, oui, mais je ne le suis pas. Ceci est une compression générale puis chiffrer ou chiffrer puis compresser une question qui pourrait s’appliquer uniquement au travail avec des fichiers simples si vous le souhaitez. La programmation est simplement le contexte de la raison pour laquelle je pose la question.
Majenko
Probablement une question mieux destinée à security.stackexchange.com
Jeff Ferland
1
Ils connaissent la compression là-bas?
Majenko

Réponses:

176

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.

Monsieur Alpha
la source
41
Plus important encore: la compression ajoute de l'entropie. Ajouter de l'entropie est bon pour votre cryptage (il est plus difficile de rompre avec les attaques par du texte clair connu).
Olli
8
En outre, le chiffrement des coûts de ressources, chiffrer un fichier plus petit prendra moins de ressources. Alors, compressez avant de chiffrer.
GAThrawn
9
@Olli - pas nécessairement si le schéma de compression ajoute du texte connu. Dans le pire des cas, imaginez que vous placiez un en-tête de 512 octets sur le dessus des données et que vous utilisiez un cryptage en mode bloc.
Martin Beckett
26
Je ne suis pas sûr de savoir pourquoi le commentaire de @ Olli aurait été voté, car il est incorrect; non seulement il est nettement moins important, mais pour un cryptage à la moitié décent, il ne devrait pas l' être du tout . C'est-à-dire que la force du cryptage ne doit absolument pas être liée à l'entropie du message.
BlueRaja - Danny Pflughoeft Le
8
Si vous compressez du tout, cela ne peut vraiment être fait qu'avant de chiffrer le message, mais gardez à l'esprit que cela peut laisser échapper des informations sur la "compressibilité" du message d'origine. Vous devrez donc vous demander s'il y a des conséquences pour ce côté-ci. canal. Considérons un fichier de taille fixe contenant tous les 0 ou un message. Le fichier tout 0 entraînera une charge plus petite sous tout schéma de compression raisonnable. Ce n'est probablement pas un problème dans ce cas d'utilisation particulier.
Edward KMETT
22

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.

Juancho
la source
12
Eh bien, c’est correct, mais a été posté 2 heures avant le jour de votre publication ... Entropy
Konerak
3

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

Tobias Braun
la source
2

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.

Prof
la source
1

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.

sqlchild
la source
1

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

Toujours entrain d'apprendre
la source
Cela semble être une répétition de la deuxième réponse acceptée. Chaque réponse devrait apporter une solution substantiellement nouvelle à la question.
fixer1234
0

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.

AbiusX
la source
2
Attendez, vous n'avez pas ça à l'envers? Je pensais que l'entropie augmentait à mesure que la redondance diminuait. Par conséquent, la compression devrait augmenter l'entropie.
Zan Lynx
Nop, moins d'entropie = plus de motifs. Le hasard a le plus d'entropie.
AbiusX
1
Mais comme il s’agit d’une entropie d’ informations , tout est une question de sens. Le hasard ne veut rien dire, donc ça ne s'applique pas. Une phrase anglaise peut avoir des lettres modifiées et signifier la même chose, donc elle a une entropie faible. Une phrase anglaise comprimée peut être illisible si un seul bit change pour en avoir le plus. Ou alors je pense.
Zan Lynx
L'entropie ne concerne pas le sens et la capacité de lire ou de comprendre, elle concerne uniquement les modèles. Les fichiers compressés sont pleins de motifs.
AbiusX
1
@AbiusX: D'accord. Les motifs. Et le moins de motifs, le plus d'entropie. Ce qui signifie que la compression qui remplace tous les motifs répétés par une seule copie augmente l'entropie.
Zan Lynx