From: Stephen Frost <sfrost@snowman.net>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alastair Turner <minion@decodable.me>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Date: Wed, 30 Dec 2020 18:49:34 -0500
Message-ID: <20201230234933.GI27507@tamriel.snowman.net> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2012281736570.2094581@pseudo>
References: <20201216001228.GC14807@momjian.us>
<CAC0Gmyy7QCvh4ey-e_XXYCHDEmaKKoeaagAFuAmhF=tS0DU4-A@mail.gmail.com>
<20201216213200.GS16415@tamriel.snowman.net>
<CAC0Gmyz9w7Axezsu66GVme3u+cR4OmqH5f-nCYNo6-cyxyA3pA@mail.gmail.com>
<20201216224331.GV16415@tamriel.snowman.net>
<CAC0GmyyVHstcMefpbCqXC25_Xg4V=Dy-q1ps1a06j9xUOL0SzQ@mail.gmail.com>
<20201218213624.GG16415@tamriel.snowman.net>
<CAC0GmyzJNXRZ5MQJYq24EiUarP+xN9Q19_cknkHmmYU=CTzHrQ@mail.gmail.com>
<20201227172526.GB17037@momjian.us>
<alpine.DEB.2.22.394.2012281736570.2094581@pseudo>
Greetings,
* Fabien COELHO (coelho@cri.ensmp.fr) wrote:
> I think that an API should be carefully thought about, without assumption
> about the underlying cryptography (algorithm, key lengths, modes, how keys
> are derived and stored, and so on), and its usefulness be demonstrated by
> actually being used for one implementation which would be what is currently
> being proposed in the patch, and possibly others thrown in for free.
Perhaps I'm misunderstanding, but this is basically what we have in the
currently proposed patch as 'cipher.h', with cipher.c as a stub that
fails if called directly, and cipher_openssl.c with the actual OpenSSL
based implementation.
> The implementations should not have to be in any particular language: Shell,
> Perl, Python, C should be possible.
I disagree that it makes any sense to pass actual encryption out to a
shell script.
> After giving it more thought during the day, I think that only one
> command and a basic protocol is needed. Maybe something as simple as
>
> /path/to/command --options arguments…
This is what's proposed- a command is run to acquire the KEK (as a hex
encoded set of bytes, making it possible to use a shell script, which is
what the patch does too).
> With a basic (text? binary?) protocol on stdin/stdout (?) for the different
> functions. What the command actually does (connect to a remote server, ask
> for a master password, open some other database, whatever) should be
> irrelevant to pg, which would just get and pass bunch of bytes to functions,
> which could use them for keys, secrets, whatever, and be easily replaceable.
Right- we just get bytes back from the command and then we use that as
the KEK. How that scripts gets those bytes is entirely up to the script
and is not an issue for PG to worry about.
> The API should NOT make assumptions about the cryptographic design, what
> depends about what, where things are stored… ISTM that Pg should only care
> about naming keys, holding them when created/retrieved (but not create
> them), basically interacting with the key manager, passing the stuff to
> functions for encryption/decryption seen as black boxes.
The API to fetch the KEK doesn't care at all about where it's stored or
how it's derived or anything like that. There's a relatively small
change which could be made to have PG request all of the keys that it'll
need on startup, if we want to go there as has been suggested elsewhere,
but even if we do that, PG needs to be able to do that itself too,
otherwise it's not a complete capability and there seems little point in
doing something that's just a pass-thru to something else and isn't able
to really be used.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, coelho@cri.ensmp.fr, bruce@momjian.us, minion@decodable.me, michael@paquier.xyz, masahiko.sawada@2ndquadrant.com
Subject: Re: Proposed patch for key managment
In-Reply-To: <20201230234933.GI27507@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox