Compress/decompress encrypted data

[jimhark]

Summary

Compress data before encryption because it reduces size by about 30%, at a
minimal additional compute cost compared to encryption and signing. This can
produce in an encrypted file that's smaller than the original.

[jdreesen]

Please be careful when combining compression & encryption.

I don't know the details of this library and am not a security expert, but apparently compressing before encrypting can leak information about plaintext content through the ciphertext length.

See here: https://crypto.stackexchange.com/questions/33737/is-it-better-to-encrypt-before-compression-or-vice-versa
and here: https://crypto.stackexchange.com/questions/29972/is-there-an-existing-cryptography-algorithm-method-that-both-encrypts-and-comp/29974#29974
and here: https://crypto.stackexchange.com/questions/15138/how-does-compression-before-encryption-leak-info-about-the-input/15152#15152

[jimhark]

@jdreesen, thank you for bringing this up so I may address these concerns.

I'm aware of CRIME and BREACH, though I'll admit they were not front of mind when I implemented compression in staticrypt. I have since reviewed these security vulnerabilities and confirmed my understanding of the threat.

Let me start at the end and assert: adding encryption to staticrypt does not expose vulnerability to these these types of attacks. I'll explain in my own words, then site references.

These vulnerabilities exploit a common technique compression algorithms use, they find repeating text and encode it more compactly. If you are communicating with an HTTP server that uses compression, and the reply contains a secret, and contains something you can control (echoing back text you provided in the request is simplest but not strictly required), then you can attempt this type of exploit. Start by making a base line request including chosen-plaintext of the desired size, and note the size of the response. Now start making guesses using chosen-plaintext of the same size with continents that may contain part of the secret. A hit is signaled when the size of the response is reduced. Each hit informs following guesses. This process doesn't need to produce the final secret, sufficiently reducing the search space of the secret's possible values is enough. This is type of attack is called an adaptive chosen-plaintext attack.

There are several prerequisites, including:

• Attacker must be able to control plaintext that is part of the encrypted data
• Attacker must be able to iterate through many attempts

Neither of these conditions is met.

The concept behind these types of attacks was published by John Kelsey in 2002:
https://iacr.org/archive/fse2002/23650264/23650264.pdf

Nearly all published works discussing compression and encryption describe how compression improves the security of encryption.

BREACH stands for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext. Adaptive Compression is right in the name.

Your reference: https://crypto.stackexchange.com/questions/33737/is-it-better-to-encrypt-before-compression-or-vice-versa

Says:

. . . compression allows an attacker who can control parts of the message that is encrypted to reveal things about the other, secret parts . . . It is most dangerous in a live protocol like TLS.

Your reference: https://crypto.stackexchange.com/questions/15138/how-does-compression-before-encryption-leak-info-about-the-input/15152#15152

Says:

The problem is not with compression and encryption, it is with the protocol that is being used

My reference: https://security.stackexchange.com/questions/20406/is-http-compression-safe

Says:

It seems risky to me. HTTP compression is fine for static resources, but for some dynamic resources served over SSL, it seems like HTTP compression might be dangerous. It looks to me like HTTP compression can, in some circumstances, allow for CRIME-like attacks.

Consider a web application that has a dynamic page with the following characteristics:

1. It is served over HTTPS.

2. HTTP compression is supported by the server (this page will be sent to the browser in compressed form, if the browser supports HTTP compression).

3. The page has a CSRF token on it somewhere. The CSRF token is fixed for the lifetime of the session (say). This is the secret that the attack will try to learn.

4. The page contains some dynamic content that can be specified by the user. For simplicity, let us suppose that there is some URL parameter that is echoed directly into the page (perhaps with some HTML escaping applied to prevent XSS, but that is fine and will not deter the attack described).

It's always good to consider and evaluate vulnerabilities and threats, but in this case CRIME, BREACH, and other compression size based side-channel attacks are not viable.

[jdreesen]

Many thanks for the elaboration. There doesn't seem to be any risk here. Thank you for taking the time to look at this and think about it :)