From: Bruce Momjian <bruce@momjian.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Date: Thu, 17 Dec 2020 22:14:14 -0500
Message-ID: <20201218031414.GA28841@momjian.us> (raw)
In-Reply-To: <X9v/Yo8sLB/GKLvt@paquier.xyz>
References: <X9gL7bD9idE2hoFt@paquier.xyz>
<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>
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...
>
> 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.
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.
> > 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 AES
> > 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.
>
> 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.
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.
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.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Attachments:
key.diff.gz (application/gzip, 28.2K) download
key-alter.diff.gz (application/gzip, 7.1K) 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: bruce@momjian.us, michael@paquier.xyz, sfrost@snowman.net, masahiko.sawada@2ndquadrant.com
Subject: Re: Proposed patch for key managment
In-Reply-To: <20201218031414.GA28841@momjian.us>
* 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