Re: [HACKERS] WIP: Data at rest encryption - Mailing list pgsql-hackers

From Toshi Harada
Subject Re: [HACKERS] WIP: Data at rest encryption
Date
Msg-id 201807130756.w6D7uV1o019294@ccmail04.silk.ntt-tx.co.jp
Whole thread Raw
In response to Re: [HACKERS] WIP: Data at rest encryption  (Antonin Houska <ah@cybertec.at>)
Responses Re: [HACKERS] WIP: Data at rest encryption  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
Hi.

I am interested in a patch of "WIP: Data at rest encryption".
This patch("data-at-rest-encryption-wip-2018.06.27.patch") is applied to PostgreSQL 11-beta 2 and it is running.

In the explanation of this patch, since "data stored during logical decoding" is written, 
we tried logical decoding by the test_decoding module, but the following error occurs when creating a slot.


pgbench_db=# SELECT * FROM pg_create_logical_replication_slot('my_slot', 'test_decoding');
ERROR:  invalid magic number B419 in log segment 000000020000000000000010, offset 0
pgbench_db=#


(Also, if you run "CREATE SUNSCRIPTION" for logical replication from another server, a similar error will occur.)

Question.
In "data-at-rest-encryption-wip-2018.06.27.patch", is logical decoding still not implemented?
Or is there a need for another logical decoding plug-in for "WIP: Data at rest encryption"?

Regards.

Antonin Houska <ah@cybertec.at> wrote:
> Ants Aasma <ants.aasma@gmail.com> wrote:
> 
> > Attached to this mail is a work in progress patch that adds an
> > extensible encryption mechanism. There are some loose ends left to tie
> > up, but the general concept and architecture is at a point where it's
> > ready for some feedback, fresh ideas and bikeshedding.
> 
> Rebased patch is attached here, in case it helps to achieve (some of) the
> goals mentioned in the related thread [1].
> 
> Besides encrypting table and WAL pages, it encrypts the temporary files
> (buffile.c), data stored during logical decoding (reorderbuffer.c) and
> statistics temporary files (pgstat.c). Unlike the previous version, SLRU files
> (e.g. CLOG) are not encrypted (it does not seem critical and the encryption
> makes torn page write quite difficult to handle).
> 
> Another difference is that we use the OpenSSL of the (tweaked) AES XTS cipher
> now.
> 
> Binary upgrade from unencrypted to encrypted cluster is not implemented yet.
> 
> 
> [1] https://www.postgresql.org/message-id/031401d3f41d$5c70ed90$1552c8b0$@lab.ntt.co.jp
> 
> -- 
> Antonin Houska
> Cybertec Schonig & Schonig GmbH
> Grohrmuhlgasse 26, A-2700 Wiener Neustadt
> Web: https://www.cybertec-postgresql.com
> 




pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Preferring index-only-scan when the cost is equal
Next
From: Amit Langote
Date:
Subject: Re: How to make partitioning scale better for larger numbers ofpartitions