From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XTS cipher mode for cluster file encryption |
Date: | 2021-10-16 16:15:05 |
Message-ID: | 20211016161505.jj3uoe75avwo6vbk@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-10-16 10:16:25 -0400, Bruce Momjian wrote:
> As a final comment to Andres's email, adding a GCM has the problems
> above, plus it wouldn't detect changes to pg_xact, fsm, vm, etc, which
> could also affect the integrity of the data. Someone could also restore
> and old copy of a patch to revert a change, and that would not be
> detected even by GCM.
> I consider this a checkbox feature and making it too complex will cause
> it to be rightly rejected.
You're just deferring / hiding the complexity. For one, we'll need integrity
before long if we add encryption support. Then we'll deal with a more complex
on-disk format because there will be two different ways of encrypting. For
another, you're spreading out the security analysis to a lot of places in the
code and more importantly to future changes affecting on-disk data.
If it's really just a checkbox feature without a real use case, then we should
just reject requests for it and use our energy for useful things.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-10-16 16:28:51 | Re: XTS cipher mode for cluster file encryption |
Previous Message | Zhihong Yu | 2021-10-16 15:31:36 | Re: Reset snapshot export state on the transaction abort |