[Cryptography] Is there a good algorithm providing both compression and encryption at the same time?

[Ray Dillinger]

Ah.

Sorry, I was missing the point. You're right about that.

If you want to deploy compress-then-encrypt, you have
to avoid adaptive compression algorithms which create
that side channel (detectable adaptation creates a side
channel about repetition).  Which means your compression
needs to be as simple as Huffman Coding with a pre-built
dictionary, like what I did in that anti-auth chat system.
It has a compression that works well for exactly one kind
of data and does no adaptation.

Interesting....  I had a sort of "vague feeling" that
adaptive compression would be a Bad Plan when I was coding
that but hadn't actually developed a fully-expressible
argument of exactly why.  So, ten-out-of-ten for having
"Holistic Zen Understanding" working for me, but that
Zen schtick is absolutely NOT what reliable, repeatable
engineering is based on, so minus ninety-nine for missing
the attack with my fully conscious mind.

Conventional encryption does usually leak message length
information: a 2 Gbyte plaintext file becomes a ~2 Gbyte
encrypted file.  If the attacker knows the length of the
original payload, the length of a compressed payload
reveals how well it compressed - meaning it reveals how
well or badly its contents matched the compression algorithm
in use, and becomes a side channel.  So it matters to NOT
use compression where the attacker knows or can control the
length of the payload - and that eliminates a lot of
uses in protocols.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150508/18d511ec/attachment.sig>