Re: Internal key management system

On Sun, 9 Feb 2020 at 01:53, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
> >Hi,
> >
> >On February 8, 2020 7:08:26 AM PST, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> >>On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
> >>>On Sat, 8 Feb 2020 at 03:24, Andres Freund <andres(at)anarazel(dot)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.
> >>>
> >>
> >>I don't think it's very likely we'll ever merge any openssl code into
> >>our repository, e.g. because of licensing. But we already have AES
> >>implementation in pgcrypto - why not to use that? I'm not saying we
> >>should make this depend on pgcrypto, but maybe we should move the AES
> >>library from pgcrypto into src/common or something like that.
> >
> >The code uses functions exposed by openssl, it doesn't copy there code.
> >
>
> Sure, I know the code is currently calling ooenssl functions. I was
> responding to Masahiko-san's message that we might eventually merge this
> openssl code into our tree.

Sorry for confusing you. What I wanted to say is to write AES
encryption code in src/common using openssl library as the first step
apart from pgcrypto's openssl code, and then merge these two code
library into src/common as the next step. That is, it's moving the AES
library pgcrypto to src/common as you mentioned. IIRC when we
introduced SCRAM we moved sha2 library from pgcrypto to src/common.

Regards,

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