On 06/18/2018 05:06 PM, Joe Conway wrote:
On 06/18/2018 10:52 AM, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway <m...@joeconway.com> wrote:
Not necessarily. Our pages probably have enough predictable bytes to aid
cryptanalysis, compared to user data in a column which might not be very
predicable.
Really? I would guess that the amount of entropy in a page is WAY
higher than in an individual column value.
Depending on the specifics of the encryption scheme, having some
amount of known (or guessable) plaintext may allow breaking the
cipher, even if much of the plaintext is not known. This is
cryptology 101, really.
Exactly
At the same time, having to have a bunch of
independently-decipherable short field values is not real secure
either, especially if they're known to all be encrypted with the
same key. But what you know or can guess about the plaintext in
such cases would be target-specific, rather than an attack that
could be built once and used against any PG database.
Again is dependent on the specific solution for encryption. In some
cases you might do something like generate a single use random key,
encrypt the payload with that, encrypt the single use key with the
"global" key, append the two results and store.
Yeah, I suppose we could even have per-page keys, for example.
One topic I haven't seen mentioned in this thread yet is indexes. That's
a pretty significant side-channel, when built on encrypted columns. Even
if the indexes are encrypted too, you can often deduce a lot of
information from them.
So what's the plan here? Disallow indexes on encrypted columns? Index
encypted values directly? Something else?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
