Re: Proposed patch for key managment

On Sun, Dec 20, 2020 at 05:59:09PM -0500, Stephen Frost wrote:
> I do generally like the idea of having the single command able to be
> used to either provide the KEK (where PG manages the keyring
> internally), or called multiple times to retrieve the DEKs (in which
> case PG wouldn't be managing the keyring).
> 
> However, after chatting with Bruce about it for a bit this weekend, I'm
> not sure that we need to tackle the second case today.  I don't think
> there's any doubt that there will be users who will want PG to manage
> the keyring and to be able to work with just a passphrase, as Bruce has
> worked to make happen here and which we have a patch for.  I'm hoping
> Bruce will post a new patch soon based on the work that he and I
> discussed today (mostly just clarifications around keys vs. passphrases
> and having the PG side accept a key which the command that's run will
> produce).  With that, I'm feeling pretty comfortable that we can move
> forward and at least get this initial work committed.

I agree with very little of this sub-discussion, but I am still reading
it to see if I can get useful ideas from it.  Looking at what we used to
do with 'passphrase', we did the prompting in the script, and did the
hash, HMAC validation, data key generation and its wrap in the server. 
With the 'cluster key' patch I just posted, the hashing of the
passphrase is removed from the server and happens only in the script,
because in many cases the hashing is not needed, and double-hashing is
less secure, so that seems like a win.

To go any further, you are starting to look at possible data key
generation in the script, either at boot time, and then wrapped with a
passphrase, or just retrieved on every boot.  That would create a larger
burden for any script, meaning a passphrase usage would have to not only
hash, which it does now, but also verify its MAC, then decrypt keys
stored in the file system, then echo those to its output, to be read by
the server.  I think this is the big point --- I have five scripts, and
only one needs to hash its input (passphrase).  If you go any farther in
pushing code into the scripts, these scripts become much harder to
write, and much harder to do error checks.

I think the common case is passphrase, so I want to optimize for that. 
Pushing anymore features into the scripts is going to make that common
case less reliable, which I am opposed to.

Also, as far as Desirability, we only have _one_ person saying people
will want more options.  I need to hear from a lot more people before
this gets added to Postgres.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee