Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

Поиск
Список
Период
Сортировка
От Antonin Houska
Тема Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Дата
Msg-id 18846.1554557353@localhost
обсуждение исходный текст
Ответ на Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: Changes to pg_dump/psql following collation "C" in the catalog
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation