Hacker News Reader

Comment by jrockway | Hacker News Reader

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 key was typed or the spacing between phonemes in a word) can be recovered by an attacker without breaking the encryption. Obvious when you say it like that ;)

View on HN

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).

Which is one of the selling points of block cyphers. They may not conceal the magnitude of the payload but they do obscure the exact byte count by rounding up. But that probably doesn't stop CRIME from being workable.

Hmm, I don't think it is really a selling point. A block cipher also implies needing a technique like CBC to prevent watermarking, and using CBC actually helps with oracle attacks.

An interesting paper on using padding to obscure length: http://cihangir.forgottenlance.com/papers/lengthhiding-corre...

Oh, I'm a fan of prepadding, and there are other surveillance problems that TLS doesn't solve that are similar to the voice analysis attack. Web pages on a site have distinct patterns of load operations and I'm certain that if we haven't established how to profile a visitor by the pattern of packets that are sent and received, that it's only a matter of time until we do.

well. My first comment would be. If your encryption algorithm produces output that can be compressed. Your encryption algorithm is broken.

As for compress. My understanding is that the inscurity has nothing much to do with timing, and everything to do with giving an attacker some "known" plaintext they can use Bayesian (Turing?) analysis against to shorten the key space.

No, read the dang article. You leak information about the content of the plaintext because you're changing the length. The crib doesn't matter with secure constructions.

1 encrypted 512bit block is always more secure than 12 512bit encrypted blocks (average compression ratio). Larger size is always a bad thing.

Problem with compress is the protocol headers give you a known part at the start of every message. Which you can then very quickly test keys against rainbow tables or other statistical means.

The best solution i know for this is to compress, then xor with a stream cipher then run into a decent block cipher.

The "compress after encrypt" is a trick question. If your data doesnt get bigger after that your encryption implementation is royally broken.

But you definately don't want every "plaintext" message starting with "..gzip".

> read herring

Freudian slip? I like it anyway.

I swear HN's font size is now too small for my eyes by default. I can't make any post without introducing a major tyop these days :)

Reply on news.ycombinator.com