Hi, On February 8, 2020 7:08:26 AM PST, Tomas Vondra <tomas.von...@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 <and...@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. And no, I don't think we should copy the implemented from pgcrypto - it's not good. We should remove it entirely. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.