On Thu, Oct 7, 2021 at 2:52 PM Stephen Frost <sfrost@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?
