Re: storing an explicit nonce

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: storing an explicit nonce
Дата
Msg-id CANwKhkOAQhWPWwcy6GYp9_-TMbY+BqXyX=ncNgwp6zTc+BqLLQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Mon, 27 Sept 2021 at 23:34, Bruce Momjian <bruce@momjian.us> wrote:
On Sun, Sep  5, 2021 at 10:51:42PM +0800, Sasasu wrote:
> Hi, community,
>
> 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.

--
Ants Aasma
Senior Database Engineer
www.cybertec-postgresql.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: improvements in Unicode tables generation code
Следующее
От: thomas@habets.se
Дата:
Сообщение: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert