Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3 - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Date
Msg-id 18846.1554557353@localhost
Whole thread Raw
In response to Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:

> On Fri, Apr 5, 2019 at 11:22 AM Antonin Houska <ah@cybertec.at> wrote:
> > > 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
>
> Hmm.  Well, I don't know what to do about that, but I think this patch
> is going to be facing an uphill battle if the encrypted and
> unencrypted WAL formats use different alignment.

Once you said this could be a problem, I thought about it a bit more. The link
above tells that stream cipher is not good for disk encryption because it's
risky to encrypt different data (e.g. old an new version of disk sector) with
the same key (or rather with the same combination of key and initialization
vector).

However WAL is a special case because here we should never need to change the
data at given position. The only exception is that unused space (sequence of
zeroes) becomes a valid record. So if we avoid encryption of the unused space,
it might be o.k. to use the stream cipher for WAL.

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



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: Changes to pg_dump/psql following collation "C" in the catalog
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation