Re: storing an explicit nonce - Mailing list pgsql-hackers

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> 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.

All of this is about limiting risks. :)

> 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.

While I certainly also appreciate that we want to get this as right as
we possibly can from the start, I strongly suspect we'll have one of two
reactions- either we'll be more-or-less ignored and it'll be crickets
from the security folks, or we're going to get beat up by them for
$reasons, almost regardless of what we actually do.  Best bet to
limit the risk ( ;) ) of the latter happening would be to try our best
to do what existing solutions already do- such as by using XTS.
There's things we can do to limit the risk of known-plaintext attacks,
like simply not encrypting empty pages, or about possible known-IV
risks, like using the LSN as part of the IV/tweak.  Will we get
everything?  Probably not, but I don't think that we're going to really
go wrong by using XTS as it's quite popularly used today and it's
explicitly used for cases where you haven't got a place to store the
extra nonce that you would need for AEAD encryption schemes.

> 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.

As long as we're clear that this initial version of TDE is with XTS then
I really don't think we'll end up with anyone showing up and saying we
screwed up by not generating a per-page nonce to store with it- the point
of XTS is that you don't need that.

Thanks,

Stephen