On Mon, Jul 18, 2022 at 6:53 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > I think a way to look at this is that this column encryption feature > isn't suitable for disguising the existence or absence of data, it can > only disguise the particular data that you know exists.
+1. 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. And even then, you still have another version of the problem, because now imagine you have one *table* that contains nothing but the value 'a' and another that contains nothing but the entire text of Don Quixote, it is going to be possible for an adversary to tell those tables apart, even with the corresponding files encrypted in their entirety. But I don't think that this means that a feature like this has no value. I think it just means that we need to clearly document how the feature works and not over-promise. -- Robert Haas EDB: http://www.enterprisedb.com
