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

From Robert Haas
Subject Re: storing an explicit nonce
Date
Msg-id CA+Tgmoak3V1JXvLuX=fU5Fqn=MCsNjZRw7oF4XNCwZpYwGB-_A@mail.gmail.com
Whole thread Raw
In response to Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Responses Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Oct 5, 2021 at 4:29 PM Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Sep 28, 2021 at 12:30:02PM +0300, Ants Aasma wrote:
> > On Mon, 27 Sept 2021 at 23:34, Bruce Momjian <bruce@momjian.us> wrote:
> > 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.
>
> Uh, yes, AES-XTS has benefits, but since it is a block cipher, previous
> 16-byte blocks affect later blocks, meaning that hint bit changes would
> also affect later blocks.  I think this means we would need to write WAL
> full page images for hint bit changes to avoid torn pages.  Right now
> hint bit (single bit) changes can be lost without causing torn pages.
> This was another of the advantages of using a stream cipher like CTR.

This seems wrong to me. CTR requires that you not reuse the IV. If you
re-encrypt the page with a different IV, torn pages are a problem. If
you re-encrypt it with the same IV, then it's not secure any more.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: storing an explicit nonce
Next
From: Tomas Vondra
Date:
Subject: Re: Compressing temporary files