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

[Natanael]

Den 7 maj 2015 23:01 skrev "Bill Cox" <waywardgeek at gmail.com>:
>
> On Wed, May 6, 2015 at 2:03 PM, Ben Laurie <ben at links.org> wrote:
>>
>> Compression is fundamentally problematic.
>>
>>
http://en.wikipedia.org/wiki/Transport_Layer_Security#CRIME_and_BREACH_attacks
>>
>> http://www.links.org/?p=127
>
> We need a way to tell the lower-level transport to not encrypt the most
sensitive data, by inserting a marker into the stream that disables/enables
compression.  This would not stop all data leakage, but at least it could
help protect security tokens and other keys.

The easier method is to just pre-encrypt, as that requires no special
treatment in the lower layers. Just feed in the data to send. Then you
don't need to worry about overzealous compression or dumb optimization. No
strange edge cases of accidental activation / deactivation of compression.

If you wish for the encryption to be done in the same software layer you
could still add an API in the transport encryption for explicitly
encrypting non-compressed sensitive data, with keys derived from the
session key, so that the data then can be detected at the other end and
decrypted by the software as necessary (no suggestions here for how to tag
it as ciphertext decryptable by API).

In the context of a receiving browser, I wonder if it makes sense with
anything but automatic transparent decryption acting as if there weren't a
second layer of encryption, because otherwise how do you even define the
access controls, why would access control to decryption be an improvement
over trusting the data flow control in the browser? I think that if you
need more control you should encrypt independently from transport
encryption. Then you can at least attempt to enforce your own policy in
your own code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150507/c44773b2/attachment.html>