21–25 of 25 posts
Earlier quoted context omitted.
The article says you encrypt, then compress. You might want to clarify that.
How can you possibly compress encrypted data? An ideal cipher should produce output indistinguishable from randomness, which is inherently difficult (read: near impossible) to compress.
Earlier quoted context omitted.
Sorry, if I said that in the video. What we do is base64(gpg(gzip(data))) We gzip the data first, then encrypt it, finally base64 encode it.
Don't compress then encrypt. It doesn't matter in this use case, but it matters very much in others. When attackers have chosen plaintext (which is virtually always), they can exploit compression to create a traffic-analytic side channel. This is the CRIME and BREACH attack on TLS, for instance. Schneier, in Applied Cryptography (which: avoid) recommended compressing before encrypting. That was bad advice. Compressio…
Earlier quoted context omitted.
Don't compress then encrypt. It doesn't matter in this use case, but it matters very much in others. When attackers have chosen plaintext (which is virtually always), they can exploit compression to create a traffic-analytic side channel. This is the CRIME and BREACH attack on TLS, for instance. Schneier, in Applied Cryptography (which: avoid) recommended compressing before encrypting. That was bad advice. Compressio…
Are you saying that compressed data should not be encrypted? We are trying to limit the amount of data we have to store in the backend K/V store. Can you provide links so I can read up on this. Thanks.
Earlier quoted context omitted.
Sorry, if I said that in the video. What we do is base64(gpg(gzip(data))) We gzip the data first, then encrypt it, finally base64 encode it.
Don't compress then encrypt. It doesn't matter in this use case, but it matters very much in others. When attackers have chosen plaintext (which is virtually always), they can exploit compression to create a traffic-analytic side channel. This is the CRIME and BREACH attack on TLS, for instance. Schneier, in Applied Cryptography (which: avoid) recommended compressing before encrypting. That was bad advice. Compressio…
Earlier quoted context omitted.
Don't compress then encrypt. It doesn't matter in this use case, but it matters very much in others. When attackers have chosen plaintext (which is virtually always), they can exploit compression to create a traffic-analytic side channel. This is the CRIME and BREACH attack on TLS, for instance. Schneier, in Applied Cryptography (which: avoid) recommended compressing before encrypting. That was bad advice. Compressio…
Are you saying that compressed data should not be encrypted? We are trying to limit the amount of data we have to store in the backend K/V store. Can you provide links so I can read up on this. Thanks.
> compressed data should not be encrypted?
That's really tricky to answer simply. "No" might be taken to mean you should store compressed data unencrypted, which would be much worse. Nor do you have to decompress already compressed data before encrypting. But if somebody hands you data to encrypt and store, don't compress it as part of the encrypting phase.