Date: Wed, 30 Dec 2020 18:49:34 -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: <20201230234933.GI27507@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rEhM+w5krfX9Wpv9"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.22.394.2012281736570.2094581@pseudo>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

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 current=
ly
> 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: She=
ll,
> 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
>=20
>   /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).

> With a basic (text? binary?) protocol on stdin/stdout (?) for the differe=
nt
> 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 functio=
ns,
> which could use them for keys, secrets, whatever, and be easily replaceab=
le.

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=E2=80=A6 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

--rEhM+w5krfX9Wpv9
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCgAGBQJf7RINAAoJEO1sijiDR2RVFKQP/RAbu0cPZeFxizWkMmZGirJX
yAn/ziJ53k4CyXoN9mchYpB22kBikn+bjP0VNkY+o4BzXzY1gjM9qJHMdpE8i8ci
SJkQqoFic4bgviPtg/+W6ahxE/kv4Rr/RfD1AUq/LV2iCk7xzFMFdBQFxsgvTuv7
qO+068zh7LmNOT6oRwTb/WAAAPB2BSTKzABP0JQxeIbZVwCI8tQ1e3VOnQmbgFcq
ziiL6xaAsyt2Kq9t7uSDDrW6EaKVh9RkXfPUvNm+HwC6rSJQHNFgsHbbuLO5ybGR
dIOgnjxo2bsJjFDMCa+qAxefRJ7BpE+fABXpuszTE0QDorOj3gDioKj8ydpYIMel
MloTIaEqtv2dYP+hD1onDQM5NuqbAr7U/Q4U5TT76Tg89HYlP81BGr8hlVj7gL5F
5wjfYmFxnbCCGv0OHAGzwznX0ap0Gc3FNv9jx1tlKQ5KIN15ZrBTpuhKBYjlD2I5
Xbblnnjbn6mJT1BdChPklb83HqVWLr8poBrB5vqNVs1rp7jEt4ujocyo0KWiJP0b
VZPYBHiEmQhfN930/iIuI3S4wQfljgX0ckKTihrZKyNeCtoYrKe6CCNQDsCSTya+
cU1ci7i2OcbJZWdR8JANjl6Ib7edCqAax1gST40IhvNoOKEXY4kJIFV8WYjhQcQr
0ECBIwXPK6snz829+4mH
=ir7C
-----END PGP SIGNATURE-----

--rEhM+w5krfX9Wpv9--