Re: Internal key management system
От | Tomas Vondra |
---|---|
Тема | Re: Internal key management system |
Дата | |
Msg-id | 20200208165323.pa7awihksyeg2nhi@development обсуждение исходный текст |
Ответ на | Re: Internal key management system (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Internal key management system
Re: Internal key management system |
Список | 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.vondra@2ndquadrant.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@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. >>> >> >>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
В списке pgsql-hackers по дате отправления: