Re: Transparent Data Encryption (TDE) and encrypted files

From: Antonin Houska <ah(at)cybertec(dot)at>
To: Ants Aasma <ants(at)cybertec(dot)at>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transparent Data Encryption (TDE) and encrypted files
Date: 2019-10-08 10:34:23
Message-ID: 44304.1570530863@antos
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ants Aasma <ants(at)cybertec(dot)at> wrote:

> On Mon, 7 Oct 2019 at 18:02, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
>> Well, do to encryption properly, there is the requirement of the nonce.
>> If you ever rewrite a bit, you technically have to have a new nonce.
>> For WAL, since it is append-only, you can use the WAL file name. For
>> heap/index files, we change the LSN on every rewrite (with
>> wal_log_hints=on), and we never use the same LSN for writing multiple
>> relations, so LSN+page-offset is a sufficient nonce.
>>
>> For clog, it is not append-only, and bytes are rewritten (from zero to
>> non-zero), so there would have to be a new nonce for every clog file
>> write to the file system. We can store the nonce in a separate file,
>> but the clog contents and nonce would have to be always synchronized or
>> the file could not be properly read. Basically every file we want to
>> encrypt, needs this kind of study.

> Yes. That is the reason why our current version doesn't encrypt
> SLRU's.

Actually there was one more problem: the AES-CBC cipher (or AES-XTS in the
earlier patch version) process an encryption block of 16 bytes at a time. Thus
if only a part of the block gets written (a torn page write), decryption of
the block results in garbage. Unlike relations, there's nothing like full-page
write for SLRU pages, so there's no way to recover from this problem.

However, if the current plan is to use the CTR mode, this problem should not
happen.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikolay Shaplov 2019-10-08 10:44:25 Re: [PATCH] Add some useful asserts into View Options macroses
Previous Message Nikolay Shaplov 2019-10-08 10:33:34 Re: [PATCH] Do not use StdRdOptions in Access Methods