From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
    Toshi Harada <harada.toshi@po.ntt-tx.co.jp>,
    "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
In-reply-to: 
 <CA+TgmoY1aWOGB06bDLDXY0O5Doc-NDvnbdz=Wajb2Fqcd9O_2g@mail.gmail.com>
References: <5907.1534140361@localhost>
 <201808150211.w7F2ApMj023097@ccmail04.silk.ntt-tx.co.jp>
 <19039.1536933944@localhost>
 <CA+TgmoawhAmdVaSYt3YLA5dsgoc-oXf72O3ybFAqiARfyTL4iA@mail.gmail.com>
 <14646.1552570130@localhost>
 <CA+Tgmoawc7hQW2SrcvVSfw8JyYV8UU4fyQ56nxKn_BtPhXfhdQ@mail.gmail.com>
 <13456.1552684223@sss.pgh.pa.us> <27465.1553168779@localhost>
 <CA+TgmoY1aWOGB06bDLDXY0O5Doc-NDvnbdz=Wajb2Fqcd9O_2g@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
   message dated "Thu, 21 Mar 2019 16:07:15 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13530.1554477762.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 05 Apr 2019 17:22:42 +0200
Message-ID: <13531.1554477762@localhost>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> wrote:

> On Thu, Mar 21, 2019 at 7:46 AM Antonin Houska <ah@cybertec.at> wrote:
> > Nevertheless, with the current version of our patch, PG should be resi=
stant
> > against such a partial write anyway because we chose to align XLOG rec=
ords to
> > 16 bytes (as long as the encryption is enabled) for the following reas=
ons:
> >
> > If one XLOG record ends and the following one starts in the same encry=
ption
> > block, both records can get corrupted during streaming replication. Th=
e
> > scenario looks like: 1) the first record is written on master (the unu=
sed part
> > of the block contains zeroes), 2) the block is encrypted and its initi=
al part
> > (i.e. the number of bytes occupied by the first record in the plain te=
xt) is
> > streamed to slave, 3) the second record is written on master, 4) the
> > containing encryption block is encrypted again and the trailing part (=
i.e. the
> > number of bytes occupied by the second record) is streamed, 5) decrypt=
ion of
> > the block on slave will produce garbage and thus corrupt both records.=
 This is
> > because the trailing part of the block was filled with zeroes during
> > encryption, but it contains different data at decryption time.
> =

> Wouldn't Tom's proposal to use a stream cipher fix all this?

Yes it would make the extra alignment unnecessary, but our solution tries =
to
meet specific requirements of disk encryption. Stream cipher appears to be
incompatible with these requirements:

https://en.wikipedia.org/wiki/Disk_encryption_theory

Currently we try to use the CBC-ESSIV mode. It's worth to mention that in =
this
mode, if the page is encrypted twice and if the plain data in the encrypti=
on
block N (i.e. block of 16 bytes) changes before the 2nd encryption, the
encrypted data will only change in blocks >=3D N. So the problem of losing
already flushed WAL records should not happen.

-- =

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