Re: storing an explicit nonce

Greetings,

* Ants Aasma (ants(at)cybertec(dot)at) wrote:
> On Mon, 27 Sept 2021 at 23:34, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Sun, Sep 5, 2021 at 10:51:42PM +0800, Sasasu wrote:
> > > It looks like we are still considering AES-CBC, AES-XTS, and
> > AES-GCM(-SIV).
> > > I want to say something that we don't think about.
> > >
> > > For AES-CBC, the IV should be not predictable. I think LSN or HASH(LSN,
> > > block number or something) is predictable. There are many CVE related to
> > > AES-CBC with a predictable IV.
> >
> > The LSN would change every time the page is modified, so while the LSN
> > could be predicted, it would not be reused. However, there is currently
> > no work being done on page-level encryption of Postgres.
> >
>
> We are still working on our TDE patch. Right now the focus is on
> refactoring temporary file access to make the TDE patch itself smaller.
> Reconsidering encryption mode choices given concerns expressed is next.
> Currently a viable option seems to be AES-XTS with LSN added into the IV.
> XTS doesn't have an issue with predictable IV and isn't totally broken in
> case of IV reuse.

Probably worth a distinct thread to discuss this, just to be clear.

I do want to point out, as I think I did when we discussed this but want
to be sure it's also captured here- I don't think that temporary file
access should be forced to be block-oriented when it's naturally (in
very many cases) sequential. To that point, I'm thinking that we need a
temp file access API through which various systems work that's
sequential and therefore relatively similar to the existing glibc, et
al, APIs, but by going through our own internal API (which more
consistently works with the glibc APIs and provides better error
reporting in the event of issues, etc) we can then extend it to work as
an encrypted stream instead.

Happy to discuss in more detail if you'd like but wanted to just bring
up this particular point, in case it got lost.

Thanks!

Stephen