On Tue, Jun 14, 2022 at 4:33 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I'm just making a general point. Why wouldn't we start out with the
> assumption that we use some pd_flags bit space for this stuff?
Well, the reason that wasn't my starting assumption is because I
didn't think of the idea.
> I'm skeptical of the idea that we want to avoid leaving any metadata
> unencrypted. But I'm not an expert on TDE, and don't want to say too
> much about it without having done some more research. I would like to
> see some justification for just encrypting everything on the page
> without concern for the loss of debuggability, though. What is the
> underlying theory behind that particular decision? Are there any
> examples that we can draw from, from other systems or published
> designs?
I don't really think there is much controversy about the idea that
it's a good idea to encrypt all of the data rather than only some of
it. I mean, that's what side channel attacks are: failure to secure
all of the information that an attacker might find useful.
Unfortunately, it seems inevitable that any TDE implementation in
PostgreSQL is going to leak some information that an attacker might
consider useful - e.g. we can't conceal how many files they are, or
what they're called, or the lengths of those files. But it seems
absolutely clear that our goal ought to be to leak as little
information as possible.
> Let's assume for now that we don't leave pd_flags unencrypted, as you
> have suggested. We're still discussing new approaches to checksumming
> in the scope of this work, which of course includes many individual
> cases that don't involve any encryption. Plus even with encryption
> there are things like defensive assertions that can be added by using
> a flag bit for this.
True. I don't think we should be too profligate with those bits just
in case somebody needs a bunch of them for something important in the
future, but it's probably fine to use up one or two.
--
Robert Haas
EDB: http://www.enterprisedb.com