Re: Proposed patch for key managment - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Proposed patch for key managment
Date
Msg-id 20201222211306.GA9170@momjian.us
Whole thread Raw
In response to Re: Proposed patch for key managment  (Alastair Turner <minion@decodable.me>)
Responses Re: Proposed patch for key managment
List pgsql-hackers
On Tue, Dec 22, 2020 at 08:15:27PM +0000, Alastair Turner wrote:
> Hi Bruce
> 
> In ckey_passphrase.sh.sample
> 
> +
> +echo "$PASS" | sha256sum | cut -d' ' -f1
> +
> 
> Under the threat model discussed, a copy of the keyfile could be
> attacked offline. So getting from passphrase to DEKs should be as
> resource intensive as possible to slow down brute-force attempts.
> Instead of just a SHA hash, this should be at least a PBKDF2 (PKCS#5)

I am satisfied with the security of SHA256.

> On Tue, 22 Dec 2020 at 15:40, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > Here is an updated patch.  Are people happy with the Makefile, its
> > location in the source tree, and the install directory name?  I used the
> > directory name 'auth_commands' because I thought 'auth' was too easily
> > misinterpreted. I put the scripts in /src/backend/utils/auth_commands.
> >
> 
> What's implemented in these patches is an internal keystore, wrapped
> with a key derived from a passphrase. I'd think that the scripts
> directory should reflect what they interact with, so
> 'keystore_commands' or 'local_keystore_command' sounds more specific
> and therefore better than 'auth_commands'.

The point is that some commands are used for keystore and some for SSL
certificate passphrase entry, hence "auth".

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

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




pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [PATCH] Automatic HASH and LIST partition creation
Next
From: Bruce Momjian
Date:
Subject: Re: Proposed patch for key managment