Re: Proposed patch for key managment

Greetings,

* Fabien COELHO (coelho(at)cri(dot)ensmp(dot)fr) wrote:
> I think that an API should be carefully thought about, without assumption
> about the underlying cryptography (algorithm, key lengths, modes, how keys
> are derived and stored, and so on), and its usefulness be demonstrated by
> actually being used for one implementation which would be what is currently
> being proposed in the patch, and possibly others thrown in for free.

Perhaps I'm misunderstanding, but this is basically what we have in the
currently proposed patch as 'cipher.h', with cipher.c as a stub that
fails if called directly, and cipher_openssl.c with the actual OpenSSL
based implementation.

> The implementations should not have to be in any particular language: Shell,
> Perl, Python, C should be possible.

I disagree that it makes any sense to pass actual encryption out to a
shell script.

> After giving it more thought during the day, I think that only one
> command and a basic protocol is needed. Maybe something as simple as
>
> /path/to/command --options arguments…

This is what's proposed- a command is run to acquire the KEK (as a hex
encoded set of bytes, making it possible to use a shell script, which is
what the patch does too).

> With a basic (text? binary?) protocol on stdin/stdout (?) for the different
> functions. What the command actually does (connect to a remote server, ask
> for a master password, open some other database, whatever) should be
> irrelevant to pg, which would just get and pass bunch of bytes to functions,
> which could use them for keys, secrets, whatever, and be easily replaceable.

Right- we just get bytes back from the command and then we use that as
the KEK. How that scripts gets those bytes is entirely up to the script
and is not an issue for PG to worry about.

> The API should NOT make assumptions about the cryptographic design, what
> depends about what, where things are stored… ISTM that Pg should only care
> about naming keys, holding them when created/retrieved (but not create
> them), basically interacting with the key manager, passing the stuff to
> functions for encryption/decryption seen as black boxes.

The API to fetch the KEK doesn't care at all about where it's stored or
how it's derived or anything like that. There's a relatively small
change which could be made to have PG request all of the keys that it'll
need on startup, if we want to go there as has been suggested elsewhere,
but even if we do that, PG needs to be able to do that itself too,
otherwise it's not a complete capability and there seems little point in
doing something that's just a pass-thru to something else and isn't able
to really be used.

Thanks,

Stephen