Re: Proposed patch for key managment

Thanks Stephen,

On Mon, 21 Dec 2020 at 00:33, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Greetings,
>
> * Alastair Turner (minion(at)decodable(dot)me) wrote:
...
> >
> > What I'd like specifically is to have the option of an external
> > keyring as a first class key store, where the keys stored in the
> > external keyring are used directly to encrypt the database contents.
>
> Right- understood, but that's not what the patch does today and there
> isn't anyone who has proposed such a patch, nor explained why we
> couldn't add that capability later.
>

I'm keen to propose a patch along those lines, even if just as a
sample. Minimising the amount of code which would have to be unpicked
in that effort would be great. Particularly avoiding any changes to
data structures, since that may effectively block adding new
capabilities.

>
> >...Your description above of changes to pass keys out
> > of the command sound like they may have addressed this.
>
> The updates are intended to make it so that the KEK which wraps the
> internal keyring will be obtained directly from the cluster key command,
> pushing the transformation of a passphrase (should one be provided) into
> a proper key to the script, but otherwise allowing the result of things
> like 'openssl rand -hex 32' to be used directly as the KEK.
>

Sounds good.

>
> > Regarding the on-disk format, separate storage of the key HMACs and
> > the wrapped keys sounds like a requirement for implementing a fully
> > external keyring or doing key wrapping externally via an OpenSSL or
> > nss tls pluggable engine. I'm still looking through the code.
>
> This seems a bit confusing as the question at hand is the on-disk format
> of the internal keyring, not anything to do with an external keyring
> (which we wouldn't have any storage of and so I don't understand how it
> makes sense to even discuss the idea of storage for the external
> keyring..?).
>

A requirement for validating the keys, no matter which keyring they
came from, was mentioned along the way. Since there would be no point
in validating keys from the internal ring twice, storing the
validation data (HMACs in the current design) separately from the
internal keyring's keys seems like it would avoid changing the data
structures for the internal keyring when adding an external option.

>
> Again, we will need the ability to perform the encryption using a simple
> passphrase provided by the user, while using multiple randomly generated
> data encryption keys, and that's what the latest set of patches are
> geared towards. I'm generally in support of adding additional
> capabilities in this area in the future, but I don't think we need to
> bog down the current effort by demanding that be implemented today.
>

I'm really not looking to bog down the current effort.

I'll have a go at adding another keyring and/or abstracting the key
wrap and see how well a true peer to the passphrase approach fits in.

Regards
Alastair