On Mon, Apr 02, 2018 at 12:46:25PM -0400, Tom Lane wrote: > Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > > I agree the attack is less likely to be applicable in typical database > > installations. I think we should move forward with considering protocol > > compression proposals, but any final result should put a warning in the > > documentation that using compression is potentially insecure. > > It seemed like the attack you described wasn't all that dependent on > whether the data is compressed or not:
I think it is. I wrote something longer about this in 2013. https://www.postgresql.org/message-id/20130115172253.ga6...@isc.upenn.edu The key idea is you can now to a radix search of a secret rather than a single 1-bit match/doesn't match oracle type attack which is not feasible when you have an high entropy low density value like a big ascii number or hex string. I do something like set my preferred email (or anything an application lets a user change) to something like a3bf and keep extending the guess as I go and sometimes I compress along with the secret and rather than have to guess a whole application session id all at once and have a work factor of O(2^128) or something I've got a very tractable search. It might not be something that a problem for everyone, but in some situations it's attackable. Garick
