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

From Masahiko Sawada
Subject Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Date
Msg-id CAD21AoBnP7eq8A09UQOHbKB6ZfA0CAsGo_A9xSDoz9jM8d4xTw@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
List pgsql-hackers
On Sat, Jul 13, 2019 at 12:33 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Fri, Jul 12, 2019 at 02:15:02PM +0900, Masahiko Sawada wrote:
> > > We will use CBC AES128 mode for tables/indexes, and CTR AES128 for WAL.
> > > 8k pages will use the LSN as a nonce, which will be encrypted to
> > > generate the initialization vector (IV).  We will not encrypt the first
> > > 16 bytes of each pages so the LSN can be used in this way.  The WAL will
> > > use the WAL file segment number as the nonce and the IV will be created
> > > in the same way.
> > >
> > > wal_log_hints will be enabled automatically in encryption mode, like we
> > > do for checksum mode, so we never encrypt different 8k pages with the
> > > same IV.
> >
> > I guess that different two pages can have the same LSN when a heap
> > update modifies both a page for old tuple and another page for new
> > tuple.
> >
> > heapam.c:3707
> >         recptr = log_heap_update(relation, buffer,
> >                                  newbuf, &oldtup, heaptup,
> >                                  old_key_tuple,
> >                                  all_visible_cleared,
> >                                  all_visible_cleared_new);
> >         if (newbuf != buffer)
> >         {
> >             PageSetLSN(BufferGetPage(newbuf), recptr);
> >         }
> >         PageSetLSN(BufferGetPage(buffer), recptr);
> >
> > Wouldn't it a problem?
>
> I had the same question.  If someone does:
>
>         UPDATE tab SET col = col + 1
>
> then each row change gets its own LSN.  You are asking if an update that
> just expires one row and adds it to a new page gets the same LSN.  I
> don't know.

The following scripts can reproduce that different two pages have the same LSN.

=# create table test (a int);
CREATE TABLE
=# insert into test select generate_series(1, 226);
INSERT 0 226
=# update test set a = a where a = 1;
UPDATE 1
=# select lsn from page_header(get_raw_page('test', 0));
    lsn
-----------
 0/1690488
(1 row)

=# select lsn from page_header(get_raw_page('test', 1));
    lsn
-----------
 0/1690488
(1 row)

So I think it's better to use LSN and page number to create IV. If we
modify different tables by single WAL we also would need OID or
relfilenode but I don't think currently we have such operations.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Re: doc: mention pg_reload_conf() in pg_hba.conf documentation
Next
From: Michael Paquier
Date:
Subject: Re: Fix typos and inconsistencies for HEAD (take 6)