Re: Internal key management system

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sehrope Sarkuni <sehrope(at)jackdb(dot)com>, cary huang <hcary328(at)gmail(dot)com>, "Moon, Insung" <tsukiwamoon(dot)pgsql(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Bruce Momjian <bruce(dot)momjian(at)enterprisedb(dot)com>
Subject: Re: Internal key management system
Date: 2020-02-08 16:53:23
Message-ID: 20200208165323.pa7awihksyeg2nhi@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

>And no, I don't think we should copy the implemented from pgcrypto -
>it's not good. We should remove it entirely.

OK, no opinion on the quality of this implementation.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-02-08 16:57:09 Re: ALTER TABLE rewrite to use clustered order
Previous Message Andres Freund 2020-02-08 15:47:24 Re: Internal key management system