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

[Francois BERENGER]

Hi,

Thanks for all the answers and pointers.

I would like to add some further remarks to my initial question, based on
the feedback I got.

I - Design priorities of the system, by decreasing order of importance:

1) simplicity (the system is minimalist)
2) speed (the system should be high performance, despite being data
intensive)
3) security (if a user choose to encrypt his data, we won't leak them out)

Interesting article I could find before asking to the list:

"On Breaking a Huffman Code"
https://people.csail.mit.edu/rivest/pubs/GMR96.pdf

So, I was wondering if people did further work in the opposite direction:
design a generic compressor that makes it extremely hard to recover
the data if you don't have access to the Huffman tree (for example).

II - Compatibility between executables of the system:

there won't be bits in message headers to change the protocol.
I plan to enforce at compile time that the executables of the system
speak a compatible protocol.
The protocol will be:
- either you speak plain text
- either you speak compressed text
  but because of the speed constraint I will support some specific
compression algorithms
  like LZ4 or snappy, not bzip2 or xz
- optionally you can sign your message before sending it
- optionally you can encrypt your message before sending it (in that order)

I plan the signing key and the encryption key to be two different keys
(they are secrets
shared by all members of the distributed system).

If I don't find an established algorithm providing both compression and
encryption
at high speed on general data (there is no assumption on what users will
transport),
then I won't provide one in the system.
I will encrypt the full output of compression (if compression is enabled).

I don't care so much about traffic analyzis or message lengths being
disclosed.
I just want the user data to be safe, if he chose so.
I won't send dummy traffic, for example, because of the high performance
constraint.

I expect the users will be computational scientists.
Before publication, it is nice to not disclose your data, so I should
provide
the functionality of encryption.

Regards,
Francois.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150510/3b87d426/attachment.html>