Compresser et ensuite crypter, ou vice-versa ?

Compresser avant de crypter. Les données comprimées peuvent varier considérablement pour de petites modifications des données sources, ce qui rend très difficile la cryptanalyse différentielle.

De plus, comme le souligne M. Alpha, si vous cryptez en premier, le résultat est très difficile à compresser.

Même si cela dépend du cas d'utilisation spécifique, je conseillerais de crypter puis de compresser. Sinon, un attaquant pourrait faire fuir des informations à partir du nombre de blocs chiffrés.

Nous supposons qu'un utilisateur envoie un message au serveur et qu'un attaquant a 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 obtenir 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, donc la fonction remplace la même information par un pointeur à la première apparition. Ainsi, si l'attaquant peut reproduire le texte en clair, la fonction de compression réduit la taille du texte en clair à la taille originale et à un pointeur. Et après le cryptage, l'attaquant peut compter le nombre de blocs de chiffrement, afin de voir si les données ajoutées sont les mêmes que celles que l'utilisateur a envoyées au serveur. Même si ce cas semble un peu construit, il s'agit d'un sérieux problème de sécurité dans TLS. Cette idée est utilisée par une attaque appelée CRIME pour faire fuir les cookies dans une connexion TLS afin de voler des sessions.

source : http://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf

Selon moi, lorsque vous comprimez un message, vous le projetez dans une dimension inférieure et il y a donc moins de bits, ce qui signifie que le message comprimé (dans l'hypothèse d'une compression sans perte) contient les mêmes informations dans moins de bits (ceux dont vous vous êtes débarrassé étaient redondants !). Vous avez donc plus d'informations par bit et par conséquent plus d'entropie par bit, mais la même entropie totale que celle que vous aviez auparavant lorsque le message n'était pas comprimé. Le caractère aléatoire est une autre affaire et c'est là que les motifs de la compression peuvent jeter un trouble.

La compression doit être effectuée avant le cryptage. Un utilisateur ne veut pas perdre de temps à attendre le transfert de données, mais il a besoin qu'il soit effectué immédiatement sans perdre de temps.