3 ms·
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
by mSparks 10y ago
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.
- unsatchmo 10y agoNo, 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.
- mSparks 10y ago1 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".