Re: Internal key management system - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Internal key management system
Date
Msg-id CA+fd4k5Oe9k5JyLVSBXVcz7A9ZgfWGp49boMavHUXPaj4+OfzA@mail.gmail.com
Whole thread Raw
In response to Re: Internal key management system  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Internal key management system
List pgsql-hackers
On Sat, 30 May 2020 at 04:20, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 1:50 AM Masahiko Sawada
> <masahiko.sawada@2ndquadrant.com> wrote:
> > However, this usage has a downside that user secret can be logged to
> > server logs when log_statement = 'all' or an error happens. To deal
> > with this issue I've created a PoC patch on top of the key manager
> > patch which adds a libpq function PQencrypt() to encrypt data and new
> > psql meta-command named \encrypt in order to  encrypt data while
> > eliminating the possibility of the user data being logged.
> > PQencrypt() just calls pg_encrypt() via PQfn(). Using this command the
> > above example can become as follows:
>
> If PQfn() calls aren't currently logged, that's probably more of an
> oversight due to the feature being almost dead than something upon
> which we want to rely.

Agreed.

The patch includes pg_encrypt() and pg_decrypt() SQL functions
inspired by Always Encryption but these functions are interfaces of
the key manager to make it work independently from TDE and are
actually not necessary in terms of TDE. Perhaps it's better to
consider whether it's worth having them after introducing TDE.

Regards,

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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Inlining of couple of functions in pl_exec.c improves performance
Next
From: godjan •
Date:
Subject: Re: Strange decreasing value of pg_last_wal_receive_lsn()