From: | Ashwin Agrawal <ashwinstar(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Ants Aasma <ants(at)cybertec(dot)at>, Sasasu <i(at)sasa(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: storing an explicit nonce |
Date: | 2021-10-07 19:31:39 |
Message-ID: | CAKSySwetMi9MuFME3V9w+rw2W86=03URtt--cYfhHwRUR+5NBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 7, 2021 at 12:12 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 7, 2021 at 2:52 PM Stephen Frost <sfrost(at)snowman(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-10-07 19:31:56 | Re: Role Self-Administration |
Previous Message | Stephen Frost | 2021-10-07 19:19:02 | Re: Role Self-Administration |