Horton

Re: Internal key management system

Masahiko Sawada <masahiko.sawada@2ndquadrant.com>

View thread
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Fabien COELHO <coelho@cri.ensmp.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Sehrope Sarkuni <sehrope@jackdb.com>, cary huang <hcary328@gmail.com>, "Moon, Insung" <tsukiwamoon.pgsql@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Joe Conway <mail@joeconway.com>, Bruce Momjian <bruce.momjian@enterprisedb.com>
Date: 2020-02-08T05:48:54Z
Lists: pgsql-hackers 
On Sat, 8 Feb 2020 at 03:24, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
> > Yeah I'm not going to use pgcrypto for transparent data encryption.
> > The KMS patch includes the new basic infrastructure for cryptographic
> > functions (mainly AES-CBC). I'm thinking we can expand that
> > infrastructure so that we can also use it for TDE purpose by
> > supporting new cryptographic functions such as AES-CTR. Anyway, I
> > agree to not have it depend on pgcrypto.
>
> I thought for a minute, before checking the patch, that you were saying
> above that the KMS patch includes its *own* implementation of
> cryptographic functions.  I think it's pretty crucial that it continues
> not to do that...

I meant that we're going to use OpenSSL for AES encryption and
decryption independent of pgcrypto's openssl code, as the first step.
That is, KMS is available only when configured --with-openssl. And
hopefully we eventually merge these openssl code and have pgcrypto use
it, like when we introduced SCRAM.

Regards,

-- 
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services