| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Subject: | Re: disable SSL compression? |
| Date: | 2018-04-02 18:28:12 |
| Message-ID: | 20180402182812.qmmcurtxtj3lqvom@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-04-02 10:25:04 -0400, Robert Haas wrote:
> In general, I'd expect compressing data to be beneficial for the
> security of encryption because it should increase the entropy of the
> encrypted bytes, but obviously it's not hard to hypothesize cases
> where the opposite is true for one reason or another.
I don't think it's actually ever a really positive thing for security to
compress before encrypting, and encrypting after should always be
useless. The problem is that that opens one hell of a sidechannel
attack, because you're suddenly leaking information about the
compressability of the transferred data. If there's any way attackers
have knowledge, or worse influence, of any of the transported data that
allows to make inferrerences about the content and potentially the key.
Whereas there should never be a observable difference in the encrypted
stream, if you use a sane cipher mode (i.e. NOT ECB).
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-04-02 18:30:50 | Re: [PATCH] Logical decoding of TRUNCATE |
| Previous Message | Andres Freund | 2018-04-02 18:13:46 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |