On Thu, Oct 7, 2021 at 12:12 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Oct 7, 2021 at 2:52 PM Stephen Frost <sfr...@snowman.net> wrote: > > Assuming that's correct, and I don't see any reason to doubt it, then > > perhaps it would make sense to have the LSN be unencrypted and include > > it in the tweak as that would limit the risk from re-use of the same > > tweak over time. > > Talking about things like "limiting the risk" makes me super-nervous. > > Maybe we're all on the same page here, but just to make my assumptions > explicit: I think we have to approach this feature with the idea in > mind that there are going to be very smart people actively attacking > any TDE implementation we ship. I expect that if you are lucky enough > to get your hands on a PostgreSQL cluster's data files and they happen > to be encrypted, your best option for handling that situation is not > going to be attacking the encryption, but rather something like > calling the person who has the password and pretending to be someone > to whom they ought to disclose it. However, I also believe that > PostgreSQL is a sufficiently high-profile project that security > researchers will find it a tempting target. And if they manage to > write a shell script or tool that breaks our encryption without too > much difficulty, it will generate a ton of negative PR for the > project. This will be especially true if the problem can't be fixed > without re-engineering the whole thing, because we're not > realistically going to be able to re-engineer the whole thing in a > minor release, and thus will be saddled with the defective > implementation for many years. > > Now none of that is to say that we shouldn't limit risk - I mean less > risk is always better than more. But we need to be sure this is not > like a 90% thing, where we're pretty sure it works. We can get by with > that for a lot of things, but I think here we had better try > extra-hard to make sure that we don't have any exposures. We probably > will anyway, but at least if they're just bugs and not architectural > deficiencies, we can hope to be able to patch them as they are > discovered. > Not at all knowledgeable on security topics (bravely using terms and recommendation), can we approach decisions like AES-XTS vs AES-GCM (which in turn decides whether we need to store nonce or not) based on which compliance it can achieve or not. Like can using AES-XTS make it FIPS 140-2 compliant or not?
