Vous devez compresser avant de chiffrer.

Le chiffrement transforme vos données en données à haute entropie, généralement indiscernables d'un flux aléatoire. La compression repose sur des modèles afin d'obtenir une réduction de taille. Étant donné que le cryptage détruit de tels modèles, l'algorithme de compression ne pourrait pas vous donner beaucoup (le cas échéant) de réduction de taille si vous l'appliquez à des données cryptées.

La compression avant le cryptage augmente également légèrement votre résistance pratique contre la cryptanalyse différentielle (et certaines autres attaques) si l'attaquant ne peut contrôler que le texte brut non compressé, car la sortie qui en résulte peut être difficile à déduire.

EDIT: J'édite cette année plus tard car ce conseil est en fait médiocre dans un cas interactif. Dans la plupart des cas, vous ne devez pas compresser les données avant de les chiffrer. Une méthode d'attaque par canal latéral connue sous le nom d '«oracle de compression» peut être utilisée pour déduire des données en texte brut dans les cas où l'attaquant peut provoquer de manière interactive le placement de chaînes dans un flux de données en clair autrement inconnu. Les attaques contre SSL / TLS telles que CRIME et BREACH en sont des exemples.

Si vous compressez après le chiffrement et que la compression fait du bien (c'est-à-dire qu'elle réduit vraiment la longueur d'une quantité non négligeable), vous pouvez abandonner le chiffrement, il est terriblement faible. Le texte chiffré ne doit pas être distingué du hasard; même les données mal chiffrées ne peuvent généralement pas être compressées.

Par conséquent, compressez avant le chiffrement. C'est pourquoi les protocoles qui traitent du cryptage incluent généralement une prise en charge de la compression, par ex. OpenPGP (section 5.6) et SSL / TLS. Dans certains scénarios, la compression peut divulguer des informations sur les données confidentielles (car la compression réduit la longueur en fonction des données , et la longueur chiffrée correspond plus ou moins à la longueur du texte brut); c'est l'idée derrière la nouvelle attaque CRIME sur SSL / TLS.

Exception marginale: si vous cryptez un message avec OpenPGP puis "ACSII armor", le résultat , c'est-à-dire l'encoder en Base64, alors cet encodage agrandit les données de 34%: 3 octets deviennent 4 caractères (plus la nouvelle ligne impaire). La compression avec DEFLATE sera efficace pour annuler cet agrandissement (grâce aux codes Huffman). C'est un cas d'utilité de la compression après le chiffrement - mais, en réalité, c'est plus de compression sur Base64, plutôt que de compression sur chiffrement.

Je recommanderais d'abord de compresser les données et de les crypter.

1. L'algorithme de compression pourrait bénéficier de la connaissance de la structure des données et cette structure serait masquée par le cryptage . Un exemple serait mp3 qui ne peut compresser que les données sonores.

2. vous auriez à crypter moins de données. Alors que lorsque vous cryptez puis compressez pour la première fois, vous ne gagnerez aucune vitesse.

Ni l'un ni l'autre: Compressez pendant le chiffrement avec un outil de chiffrement conçu pour faire les deux en toute sécurité, tel que GPG / OpenPGP.

C'est fondamentalement la réponse de Thomas Pornin juste plus directe, donc les lecteurs pressés ne comprennent pas mal les subtilités de ce que Thomas Pornin explique dans sa réponse. La question exprime une fausse dichotomie. Si l'OP (et le lecteur) pense que les première et deuxième étapes sont l'exécution de deux outils différents comme gzip et gpg:

1. Si vous cryptez d'abord, la compression ne fera pas grand-chose, en plus de réduire l'inflation Base64 de 34% de «l'armure ASCII» mentionnée par @ThomasPornin.

2. Si vous compressez d'abord, le chiffrement est moins sécurisé, vulnérable aux attaques comme celles mentionnées par @ThomasPornin.

La compression après le chiffrement peut ne pas faire la fonction réelle de compression des données car elle ne réduira pas beaucoup la taille. Mais le cryptage après compression réduit la taille mais il n'effectuera pas le bon fonctionnement du cryptage car des attaques comme CRIME peuvent se produire.

À titre d'exemple dans les requêtes Web, les en-têtes contiennent des cookies Web secrets, donc la compression des en-têtes avant le cryptage révéler ces informations secrètes à l'extérieur.

Par conséquent, il est sage de faire une compression sélective qui ne compresse que les données non secrètes dans la page, puis le chiffrement aura du sens et empêchera l'extraction d'informations secrètes.