Re: Proposed patch for key managment

Greetings,

* Alastair Turner (minion(at)decodable(dot)me) wrote:
> On Mon, 21 Dec 2020 at 00:33, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * 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.

Ok, sure, but are there such changes that would need to be made for this
case...? Seems to only be speculation at this point.

> > > 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.

This doesn't strike me as very clear- specifically which HMACs are you
referring to which would need to be stored separately from the internal
keyring to make it possible for an external keyring to be used?

> > 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.

Great, glad to hear that.

> 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.

Having patches to review and consider definitely helps, imv.

Thanks,

Stephen