On Tue, Jun 14, 2022 at 4:33 PM Peter Geoghegan <p...@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
