Re: Transparent column encryption - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Transparent column encryption
Date
Msg-id CAAWbhmgNL5wNzy-LcnGeyW7KL8_pt0VnD46qn+L8OfeQP+g8uA@mail.gmail.com
Whole thread Raw
In response to Re: Transparent column encryption  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Transparent column encryption
List pgsql-hackers
On Mon, Jul 18, 2022 at 9:07 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Even there, what can be accomplished with a feature that only encrypts
> individual column values is by nature somewhat limited. If you have a
> text column that, for one row, stores the value 'a', and for some
> other row, stores the entire text of Don Quixote in the original
> Spanish, it is going to be really difficult to keep an adversary who
> can read from the disk from distinguishing those rows. If you want to
> fix that, you're going to need to do block-level encryption or
> something of that sort.

A minimum padding option would fix the leak here, right? If every
entry is the same length then there's no information to be gained, at
least in an offline analysis.

I think some work around that is probably going to be needed for
serious use of this encryption, in part because of the use of text
format as the canonical input. If the encrypted values of 1, 10, 100,
and 1000 hypothetically leaked their exact lengths, then an encrypted
int wouldn't be very useful. So I'd want to quantify (and possibly
configure) exactly how much data you can encrypt in a single message
before the length starts being leaked, and then make sure that my
encrypted values stay inside that bound.

--Jacob



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Transparent column encryption
Next
From: Dean Rasheed
Date:
Subject: Re: Make name optional in CREATE STATISTICS