Greetings, * Alastair Turner (min...@decodable.me) wrote: > On Sun, 20 Dec 2020 at 22:59, Stephen Frost <sfr...@snowman.net> wrote: > > Yes, it's true that after things are implemented it can be more > > difficult to change them- but if you're concerned about the specific > > on-disk format of the keyring then please help us understand what your > > concern is there. The concern you've raised so far is just that you'd > > like an option to have an external keyring, and that's fine, but we are > > also going to need to have an internal one and which comes first doesn't > > seem particularly material to me. I don't think having one or the other > > in place first will really detract or make more difficult the adding of > > the other later. > > 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. > The examples in this discussion so far have all put the internal > keyring between any other crypto infrastructure and the file > encryption process. 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. > 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..?). 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. Thanks, Stephen
signature.asc
Description: PGP signature
