Date: Thu, 31 Dec 2020 09:40:49 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Bruce Momjian <bruce@momjian.us>, Alastair Turner <minion@decodable.me>,
	Michael Paquier <michael@paquier.xyz>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Message-ID: <20201231144048.GL27507@tamriel.snowman.net>
References: <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>
 <20201230234933.GI27507@tamriel.snowman.net>
 <alpine.DEB.2.22.394.2012311111380.3573723@pseudo>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="yY6OajYROBmoEVZC"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2012311111380.3573723@pseudo>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--yY6OajYROBmoEVZC
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Fabien COELHO (coelho@cri.ensmp.fr) wrote:
> >>The implementations should not have to be in any particular language: S=
hell,
> >>Perl, Python, C should be possible.
> >
> >I disagree that it makes any sense to pass actual encryption out to a
> >shell script.
>=20
> Yes, sure. I'm talking about key management. For actual crypto functions,
> ISTM that they should be "replaceable", i.e. if some institution does not
> believe in AES then they could switch to something else.

The proposed implementation makes it pretty straight-forward to add in
other implementations and other crypto algorithms if people wish to do
so.

> >>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=E2=80=A6
> >
> >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).
>=20
> Yep, but that is not what I'm trying to advocate. The "KEK" (if any), wou=
ld
> stay in the process, not be given back to the database or command using i=
t.
> Then the database/tool would interact with the command to get the actual
> per-file keys when needed.

"When needed" is every single write that we do of any file in the entire
backend.  Reaching out to something external every time we go to use the
key really isn't sensible- except, perhaps, in the case where we are
doing full crypto off-loading and we don't actually have to deal with
the KEK or the DEK at all, but that's all on the cluster encryption
side, really, and isn't the focus of this patch and what it's bringing-
all of which is needed anyway.

> >[...] The API to fetch the KEK doesn't care at all about where it's stor=
ed
> >or how it's derived or anything like that.
>=20
> >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 somethi=
ng
> >else and isn't able to really be used.
>=20
> I do not understand. Postgres should provide a working implementation,
> whether the functions are directly inside pg or though an external proces=
s,
> they need to be there anyway. I'm trying to fix a clean, possibly external
> API so that it is possible to have something different from the choices m=
ade
> in the patch.

Right, we need a working implementation that's part of core, that's what
this effort is trying to bring.

Thanks,

Stephen

--yY6OajYROBmoEVZC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJf7eLwAAoJEO1sijiDR2RV9H4P/05brEiVus0XRF8d6K54fhZR
wZL49wuui2+3Xv92cJCn0j9LRwKvDntYVEEGExhLEZTwEvCg6qqj9qq/Soj+c0O8
HhsazthJIuclmStjRVtCEHyi9etySuRdd2LUlT2EQnGR2ezJgY+ME5Yk7ZT+JuEh
wptCsHUF0OsgKcHWcUd0GVG3S/WImEooqbe5QJ2dbGHq3vAdYsDwsP43IF/m4SF6
u6T/QMM7zQSKMgvzg28zBVOsP3MlBSldV28PRB0J60rMLvt24knwXZgZ6+36YYMP
6h2hh/dXXwTqyUEuifza1u/2XKsi8iohbP0cRk4zpjeloAzaF5w8LiajpbpPiaUP
Bqk3YvyOK6sHxj+31tK0xpH+9EUraYTIgLYBvdCMm0H6BaB3fni14RHJoV125QtD
+KBDfSkZJN3NQyoK2P6PRWSTmjmiIyArfQ/dZGT/6ggBmmzPCAkb26a7eRrwd6Ts
28hdfmiYUd027NhgGemB21JzQ/Sn7xHZiTIgrsck3KGXdvZet5U0jsG0rRoxLR1Y
v4eb7zAcXTMiHg5SJkP0duMgCLSK0+IJXNe4eWkHi3tkXS7sxsJ3P7YKmTcrXxJt
yZAnZgByBNAGr6lOVdYTO0evBA1kgCDTMUShTbh4HRWsIj/Yct3VgYPwoU5//hDQ
DPDx52PX1ediwR+qTRKF
=VToy
-----END PGP SIGNATURE-----

--yY6OajYROBmoEVZC--