5
$\begingroup$

would compress and encrypt on data comromise security for PGP like application, would it be secure for use in Encrypted Messaging?

I have heard its safe for data at rest encryption , i have heard about CRIME and BREACH attacks on TLS, i am concerned if it would affect PGP like applications and the case of encrypted messengers.

$\endgroup$
6
  • $\begingroup$ What are you interested in compressing? Files? There's no need to perform compression for text messages. Signal and WhatsApp compress images. $\endgroup$ Jan 28, 2023 at 10:03
  • $\begingroup$ @samuel-lucas6 i am interested in compressing all sorts of files including text files. but i am willing to not compress if it decreases security in my use case. $\endgroup$ Jan 28, 2023 at 13:42
  • $\begingroup$ My advice would be don't compress unless you need to due to storage/bandwidth constraints. There should be no need to compress text files. It makes more sense in the case of encrypting a directory by grouping the files together into a ZIP file but even that can be done without compression. What's confusing about your question is that the two use cases are completely different (file encryption vs encrypted messengers). $\endgroup$ Jan 28, 2023 at 16:30
  • $\begingroup$ By default (open)PGP/GPG compresses before encryption. It's unclear if the question's "compress" is that compression, or separate. It's also unclear if it's envisioned to use symmetric or asymmetric crypto (GPG does both), and (in the asymmetric case) if the data would be signed. Also it's unclear what "com(p)romise security" covers (confidentiality only? or also something else? Would being able to tell if the plaintext is compressible be considered a significant confidentiality breach?) $\endgroup$
    – fgrieu
    Jan 28, 2023 at 19:32
  • $\begingroup$ @samuel-lucas6 sorry for the confusion I actually asked 2 different questions one for PGP like usecase and other for encrypted messenging in a single question , which caused confusion . $\endgroup$ Jan 29, 2023 at 4:23

2 Answers 2

4
+50
$\begingroup$

Compression before encryption can leak information in a few ways.

Compression occurs on the plaintext, encryption is on the result of compression, and then there's a public and quite precise relation between size of result of compression and size of ciphertext (including if there's also compression in the encryption, as is the case by default in GPG, an implementation of (Open)PGP). Therefore the size of the result of compression of the plaintext is known to great precision (often, exactly) to adversaries. So is the nature of the compression. And that leaks some information about the plaintext. Some examples:

  • If the plaintext is known to be constant length, that tells it's compressibility, and that's an important information. In particular, for voice truncated into short constant-time frames with audio compression, as in VoIP, according to this 2008 paper that can be enough to discern some phrases! And as the saying goes, “Attacks always get better; they never get worse” (attributed to the NSA by Bruce Schneier).
  • Similarly, if long text messages are broken into separate segments of mostly fixed size and they are individually compressed, it will me possible to distinguish some features of the text (like what alphabet is used, or which of two different persons wrote it, if they have different typing habits).
  • For photographs, size of ciphertext is an excellent indicator of which of several images was sent, and compression kills attempts to hide this by making the images of identical size. Even if such images are sent a single time, things like if they where on focus or not, or if they are taken at day or night, are likely to leak.

When using pure encryption (e.g. a block cipher in CTR, CBC, OFB mode), adversaries can alter ciphertext, so that altered compressed data will reach the de-compressor on the receiver side. Depending on de-compressor and alteration, the de-compressor can crash (that's common, and is often enough for a so-called Denial of Service attack), abort with error which perhaps can be sensed by adversaries, or output corrupted data which perhaps can leak in part to adversaries (e.g. the length of the corrupted data might be measured by timing the behavior of the receiver). Repeating observation of the behavior of the receiver for different alterations of the ciphertext can conceivably leak more and more information on the plaintext, similar to some padding oracle attack. Feasibility depends a lot on details of the compression and of the receiver setup. Fortunately, authenticated encryption (after compression and before decompression) prevents such attacks, and is now widely available, including in modern ciphersuites of OpenPGP/GPG.

Also, compression and decompression algorithms are almost never designed to be constant-time, much less to resist other side-channel or fault attacks, and there could be some information leak. However that's true for most data-processing algorithms in common use, so this concern is general when sensitive data is manipulated, rather than specific to using compression.

$\endgroup$
3
$\begingroup$

Just a little clarification: PGP is mainly used for data on the move as it encrypts messages between two keys/accounts (unless you use symmetrical options which isn't really its raison d'etre).

Both CRIME and BREACH attacks focus on secrets retrieval, typically session cookies. They both require multiple autonomous server responses to small variations in attacker generated input.

That's not the modus operandi of PGP. In PGP messaging information is compressed and then encrypted once for each sender generated message. Yes, the size of the compressed message can be inferred from the encrypted .pgp file. In the case of automatic cookie transport, any attacker has a good idea of the original size, so correlated compressive attacks are possible. In the messaging situation, the attacker doesn't really know the original message size, so the .pgp file isn't all that leaky. And there's only one message, not under attacker control.

E.g. A 1,000,000 file of zeros creates a .pgp file of 1598 bytes (encrypted to a random recipient). But if you didn't know that I sent a million bytes of nothing, what could an attacker infer or what significant advantage would he obtain? Thus TLS/CRIME/BREACH attacks are inapplicable to a PGP message.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.