Date: Fri, 18 Dec 2020 08:18:53 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: 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: <20201218131853.GA16415@tamriel.snowman.net>
References: <20201215031902.GB14596@momjian.us>
 <X9hHoQcZ11pBtgnz@paquier.xyz>
 <20201215210212.GG14596@momjian.us>
 <X9lhi1ht04I+v/rV@paquier.xyz>
 <20201216220412.GB4527@momjian.us>
 <X9qXuLekePLRYrB2@paquier.xyz>
 <20201217163954.GY16415@tamriel.snowman.net>
 <20201217171022.GE23260@momjian.us>
 <X9v/Yo8sLB/GKLvt@paquier.xyz>
 <20201218031414.GA28841@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="zHiB4nxY3pkYfS0t"
Content-Disposition: inline
In-Reply-To: <20201218031414.GA28841@momjian.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--zHiB4nxY3pkYfS0t
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Fri, Dec 18, 2020 at 10:01:22AM +0900, Michael Paquier wrote:
> > On Thu, Dec 17, 2020 at 12:10:22PM -0500, Bruce Momjian wrote:
> > > On Thu, Dec 17, 2020 at 11:39:55AM -0500, Stephen Frost wrote:
> > >> I don't think there's any need for us to implement a fallback
> > >> implementation of AES.  I'm not entirely sure we need it for hashes
> > >> but since we've already got it...
> >=20
> > We need fallback implementations for cryptohashes (MD5, SHA1/2) and
> > HMAC because we have SCRAM authentication, pgcrypto and SQL functions
> > that should be able to work even when not building with any SSL
> > libraries.  So that's here to stay to ensure compatibility with what
> > we do.  All this stuff is already in the tree for ages, it was just
> > not shaped for a more centralized reuse.
>=20
> One question is whether we want to support cluster file encryption
> without OpenSSL --- right now we can't.  I am wondering if we really
> need the hardware acceleration of OpenSSL for AES so doing our own AES
> implementation might not even make sense, performance-wise.

No, I don't think we need to support file encryption independently of
any library being available.  Maybe some day we will, but that should
really just be another option to build with.

Guess it wasn't clear, but I was being a bit tounge-in-cheek regarding
the idea of dropping SCRAM support if we aren't built with OpenSSL.

> > > Agreed.  I think there is serious risk we would do AES in a different
> > > way than OpenSSL, especially if I did it.  ;-)  We can add a native A=
ES
> > > one day if we want, but as stated by Michael Paquier, it has to be
> > > tested so we are sure it returns exactly the same values as OpenSSL.
> >=20
> > I think that it would be good to put some generalization here, and
> > look at options that are offered by other SSL libraries, like libnss
> > so as we don't finish with a design that restricts the use of a given
> > feature only to OpenSSL.
>=20
> Uh, you mean the C API or the user API?  I don't think we have any
> OpenSSL requirement at the user level, except that my examples use
> command-line openssl to generate the passphrase.

What I would be thinking about with this are really three pieces-

- C API for libpq (not relevant for this, but we have had issues in the
  past with exposing OpenSSL-specific things there)

- C API in backend - we should try to at least set up the structure to
  allow multiple encryption implementations, either via different
  libraries or if someone feels it'd be useful to write a built-in
  implementation, but as I mentioned just a moment ago, we aren't going
  to get this perfect and we should accept that.

- User API - we should avoid having OpenSSL-specific bits exposed to
  users, and I don't think we do today, so I don't think this is an
  issue at the moment.

> I split apart my patch to create cipher{_openssl}.c and hmac{_openssl}.c
> so the single HMAC function is not in the cipher file anymore, attached.

Will try to look at this soon, but in general the idea seems right.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJf3Kw9AAoJEO1sijiDR2RVQeUP/AmBhKmldS4NhWGLRRI2Ji3Y
gP0xaJf8FxeUEFTxaQ/EEqbZsgggXjvbyh/QtHdQlGrLytnRO+RMT1fkxeqDf7F9
5GOA0O9KqW4sePPMU2acfS9EIglwuBVZUa+EpSwIYjPlrTpFY7VV9HkOzZcFwAer
fxCqhO91kaUyX969+mtiYYutZ/lK2V/rvWMhwR8MRqM7GcyVheHw1pEZEVL09759
/FFw0EoLjLWuNGv91fdszknQoggheC4tznBKB43kRryI+KmhcLrk7zO3epI8u+Lg
6j7SeVFOv/xTVQNr8E/FrUDUHbTmuTs4rfQ2dm0unZaZVngPD6tSSAyiGoQSEHxu
1nIasu9CXGeFTIncp+kQEB0IaYfBViQFDcdJq/Z9jmrC/iwZKPOkoD4Dr9odtGJ5
OjvTcXhkMVHRQtxp/LvbhT2C+b/ORIr6F8o2mRAGClhSdYEGH+YgEnuLF8IBZS/k
uh8liHp9m7X3pEXCH45gBUaA+cwbPatL6/zbMII1tbXpum/AcdCQul1JzjgayRmb
y0KVmjX7bC8eqEnhJsbdUVN24MX3jpe8WUmIYbtw1DJ/u6fV7Clz9Ml3z1yzFoZp
R1KEuq6wXR/EVNAiPiXBj9cWdG5MZMoDRK8k8oApLoCWv9IhwTejBZ+txICMIM0N
KkO5BgjzzAoQOy6ChiJy
=djLe
-----END PGP SIGNATURE-----

--zHiB4nxY3pkYfS0t--