Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Should you encrypt or compress first?”

blog.appcanary.com

Post reply on HN
Print view View original

171–180 of 249 posts

Re: “Should you encrypt or compress first?”

#171

Post by lisper »

s_tec wrote: post #162
lisper wrote: post #71

Earlier quoted context omitted.

Why would you use a stream cipher to encrypt a document?

The AES-GCM mode of operation turns the AES block cipher into a stream cipher. Doing this makes it possible to add authentication on top for relatively cheap. The ChaCha20-poly1305 has a similar construction. These are the two most secure and efficient ciphers available in TLS, so they get a lot of use. If you are sending documents over HTTPS, you definitely want them encrypted with one of these two.

Fair enough, I concede the point.

Re: “Should you encrypt or compress first?”

#172

Post by DougBTX »

lisper wrote: post #151
jrockway wrote: post #145

Earlier quoted context omitted.

I think compression is a read herring here. Think about keyboard-interactive ssh authentication. Whether or not the data is compressed, the timing of the packets depends on the timing between when you pressed the keys on your keyboard. Thus information is leaked, and compression was not involved. Therefore, I feel like compression complicates the discussion unnecessarily. Information that's not encrypted (the time a…

Well, yeah, but the point is that compression can cause the leakage of information through timing that would not otherwise have leaked.

Yes, in other words compression can move information from the content of the data (which is encrypted) to the size of the data (which is not encrypted).

Re: “Should you encrypt or compress first?”

#173

Post by niftich »

lisper wrote: post #71
witty_username wrote: post #64

Earlier quoted context omitted.

@lisper Stream ciphers.

Why would you use a stream cipher to encrypt a document?

In GCM, the 'C' is for counter, and hence turning AES into a stream cipher. This part is usually known as 'AES-CTR'. The 'G' is Galois for 'Galois field multiplication', which allows for a parallelizable way of computing a MAC. AES-GCM packages AES-CTR (a stream cipher made from a block cipher) and GMAC (the Galois MAC) together into a primitive. This type of scheme, which combines confidentiality, integrity, and authenticity is called 'authenticated encryption with associated data' (AEAD) [1]. A stream cipher is the easiest way of accomplishing that the cipherstream will safely expand to cover all the plaintext.

Other famous AEAD schemes are:

- CCM (Counter with CBC-MAC), packages AES-CTR and CBC-MAC together in an authenticate-then-encrypt regime

- ChaCha20-Poly1305, which packages together the stream cipher ChaCha20 and the MAC Poly1305.

[1] https://en.wikipedia.org/wiki/Authenticated_encryption

Re: “Should you encrypt or compress first?”

#174

Post by admax88q »

lisper wrote: post #39
orlp wrote: post #14

There's no compress or encrypt _first_. It's just compress or not, before encrypting. If security is important, the answer to that is no, unless you're an expert and familiar with CRIME and related attacks. Compression after encryption is useless, as there should be NO recognizable patterns to exploit after the encryption.

> If security is important, the answer to that is no It's a little more nuanced than that. Compression may cause information leaks or it can prevent them depending on the circumstances. If you're encrypting an audio stream, then compressing it first can cause leaks. If you're encrypting a document, then compressing it first may prevent leaks.

You can't compress after encryption.

Encrypted content should be indistinguishable from random data. So encrypt than compress shouldn't be able to yield any reasonable compression.

Re: “Should you encrypt or compress first?”

#175

Post by mikeash »

b101010 wrote: post #169
mikeash wrote: post #78

Earlier quoted context omitted.

It's pointless. If you sign the encrypted data, then once the signature is verified in the receiver, you know that the decrypted data is also good. Repeating the signature just wastes time and space.

After some thought, The only advantage of signing before and after i can think of is without it you are left with the (theoretical?) problem of not knowing if the output from your implementation/version of the utility to decrypt/decompress is identical to the senders input to their implementation of the utility if the sender only signs the compressed/encrypted version. Of course, if the compression/encryption method…

I can definitely see a use for checking the integrity of the decrypted/decompressed data. Of course, implementation bugs or hardware defects could wreck your data after that stage, but increasing coverage can still help.

Verifying data integrity isn't exactly the same as authenticating a message, so I think you'd probably want to use a simpler scheme for that. For example, a basic CRC would suffice for most use cases there.

Re: “Should you encrypt or compress first?”

#176

Post by x1798DE »

mikeash wrote: post #154
x1798DE wrote: post #146

Earlier quoted context omitted.

Except what about the case where someone can spoof that an encrypted message came from them? In that case, you want the signature somewhere inaccessible, so that they can't selectively strip it off.

I don't understand what you mean. Your signature scheme is either secure or it isn't. If an attacker can spoof or strip the signature and have you accept it, then it isn't secure and it doesn't matter where you put it. If they can't, then you can have it be in the outermost layer.

Well the scenario I'm envisioning is that sign-then-encrypt guarantees that no signatures were stripped off in transit, that's all. It prevents people from saying that an encrypted message (which they were unable to read) came from them, even though they didn't encrypt it.

I think it's probably most important in trust on first use scenarios, where an MITM in position during trust on first use can strip off a plaintext signature and re-sign the encrypted message with their own key - if there's a signature inside the ciphertext that matches the signature outside, you can detect something like that.

Not sure that it really comes up much, though.

Re: “Should you encrypt or compress first?”

#177

Post by zielmicha »

panic wrote: post #37

Has there been any research into compression that's generally safe to use before encryption? E.g., matching only common substrings longer than the key length would (I think?) defeat CRIME at the cost of compression ratio.

I'm working (finishing paper) on an algorithm compatible with deflate/gzip that is safe to use before encryption (i.e. it is guaranteed to not leak random secrets cookies). It's a bit more complex than your suggestion - matching common substrings longer than key length would still be vulnerable as substring boundary may still fall inside secret.

Re: “Should you encrypt or compress first?”

#178

Post by mjevans »

geofft wrote: post #17
tomp wrote: post #2

I don't understand... Why couldn't you do CRIME with no compression as well? Assuming you can control (parts of) the plaintext, surely plaintext+encrypt gives you more information than plaintext+compress+encrypt?

If you control parts of the plaintext, a well-designed cipher doesn't tell you anything about the rest of the plaintext. But if you control parts of the plaintext, a compression algorithm will absolutely tell you information about the rest of the plaintext. That's its job—identifying similarities between different parts of the plaintext. And it will leak that information in the form of the size of its output, and the…

Actually in the context of security compressing the data you're about to encrypt still matters. The problem exposed by the CRIME exploit (and anything similar) is that the size of the payload also can be an indication of the data within it. To combat this, systems which are exchanging data interactively (in a stream) should further pad messages /up to/ a target size (which might be random per message).

As I mentioned elsewhere there's no reason that data can't also be potentially useful (though it does become difficult to ensure that this isn't also a source of attack).

Re: “Should you encrypt or compress first?”

#179

Post by mjevans »

Miner49er wrote: post #102
richard_todd wrote: post #72

Earlier quoted context omitted.

If security is the top concern, making all encrypted messages the same length would be ideal as far as I can tell. That way, all you are giving away is an upper bound on the message size. Padding with random noise to a uniform length (with the payload either compressed or not) and then encrypting should be the most secure option.

What's the point of compressing if you're just going to pad it anyway? If you're worried about security just encrypt and don't compress.

The point in that case is to combat plain text (known value) attacks.

Precisely how the padding / extra padding is distributed within the data stream to be encrypted is also an issue. The goal is to make it very difficult to guess where data will be represented if you do happen to know the plain text.

Re: “Should you encrypt or compress first?”

#180

Post by dghughes »

jrockway wrote: post #145
lisper wrote: post #39

Earlier quoted context omitted.

> If security is important, the answer to that is no It's a little more nuanced than that. Compression may cause information leaks or it can prevent them depending on the circumstances. If you're encrypting an audio stream, then compressing it first can cause leaks. If you're encrypting a document, then compressing it first may prevent leaks.

I think compression is a read herring here. Think about keyboard-interactive ssh authentication. Whether or not the data is compressed, the timing of the packets depends on the timing between when you pressed the keys on your keyboard. Thus information is leaked, and compression was not involved. Therefore, I feel like compression complicates the discussion unnecessarily. Information that's not encrypted (the time a…

> read herring

Freudian slip? I like it anyway.

Post reply on HN