Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Дата
Msg-id 20190710170447.GA2501@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Bruce Momjian <bruce@momjian.us>)
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Ryan Lambert <ryan@rustprooflabs.com>)
Список pgsql-hackers
On 2019-Jul-10, Bruce Momjian wrote:

> *  Using the LSN as part of the nonce fixes both problems, and has a
>    third benefit:
> 
>     *  We don't need to decrypt/re-encrypt during CREATE DATABASE since
>        the page contents are the same in both places, and once one
>        database changes its pages, it gets a new LSN, and hence a new
>        nonce/IV.
> 
>     *  For each change of an 8k page, you get a new nonce/IV, so you
>        are not encrypting different data with the same nonce/IV
> 
>     *  This avoids requiring pg_upgrade to preserve database oids.

An ignorant question -- what is it that gets stored in the page for
decryption use, the nonce or the IV derived from it?  I think if you
want to store the nonce, you'd have to store the database OID, because
otherwise how do you know which database OID to use to determine the
full nonce after cloning a database?  You already have the table OID in
the catalog and the LSN in the page header, so you're only missing the
database OID.  (Assuming you make the nonce be database OID || relation
OID || page LSN)

Also, how are key changes handled?  Do we need to store a key identifier
in each page?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Dent John
Дата:
Сообщение: Re: (select query)/relation as first class citizen
Следующее
От: Andres Freund
Дата:
Сообщение: Re: buildfarm's typedefs list has gone completely nutso