From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Alastair Turner <minion(at)decodable(dot)me> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Subject: | Re: Proposed patch for key management |
Date: | 2021-01-04 17:56:18 |
Message-ID: | 20210104175618.GD7432@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 2, 2021 at 12:47:19PM +0000, Alastair Turner wrote:
> If keys can have arbitrary scope, then the pg backend won't know what
> to ask for. So the API becomes even simpler with no specific request
> on stdin and all the relevant keys on stdout. I generally like this
> approach as well, and it will be the only option for some
> integrations. On the other hand, there is an advantage to having the
> key retrieval piece of key management in-process - the keys are not
> being passed around in plain.
>
> There is also a further validation task - probably beyond the scope of
> the key management patch and into the encryption patch[es] territory -
> checking that the keys supplied are the same keys in use for the data
> currently on disk. It feels to me like this should be done at startup,
> rather than as each file is accessed, which could make startup quite
> slow if there are a lot of keys with narrow scope.
We do that already on startup by using GCM to validate the KEK when
encrypting each DEK.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-01-04 17:59:22 | Re: Bug in numeric_power() if exponent is INT_MIN |
Previous Message | Pavel Stehule | 2021-01-04 17:56:17 | Re: [HACKERS] [PATCH] Generic type subscripting |