On Dec 21, 2007 12:40 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > On Dec 20, 2007 6:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> So if you want something other than endless arguments to happen,
> >> come up with a nice key-management design for encrypted function
> >> bodies.
>
> > Maybe a key management solution isn't required. If, instead of
> > strictly wrapping a language with an encryption layer, we provide
> > hooks (actors) that have the ability to operate on the function body
> > when it arrives and leaves pg_proc, we may sidestep the key problem
> > (leaving it to the user) and open up the doors to new functionality at
> > the same time.
>
> I think you're focusing on mechanism and ignoring the question of
> whether there is a useful policy for it to implement. Andrew Sullivan
> argued upthread that we cannot get anywhere with both keys and encrypted
> function bodies stored in the same database (I hope that's an adequate
> summary of his point). I'm not convinced that he's right, but that has
> to be the first issue we think about. The whole thing is a dead end if
> there's no way to do meaningful encryption --- punting an insoluble
> problem to the user doesn't make it better.
Well, there is no 'one size fits all' policy. I'm still holding out
that we don't need any specific designs for this...simply offering the
example in the docs might get people started (just thinking out loud
here):
create function encrypt_proc(proname text, prosrc_in text, prosrc_out
out text) returns text as
$$
declare
key bytea;
begin
-- could be a literal variable, field from a private table, temp
table, or 3rd party
-- literal is dangerous, since its visible until 'create or
replaced' but thats maybe ok, depending
key := get_key();
select magic_string || encode(encrypt(prosrc_in, key, 'bf'),
'hex'); -- magic string prevents attempting to unencrypt non-encrypted
functions.
end;
$$ language plpgsql;
-- ordering of actors is significant...need to think about that
alter language plpgsql add actor 'encrypt_proc' on input;
alter language plpgsql add actor 'decrypt_proc' on output;
If that's not enough, then you have build something more structured,
thinking about who provides the key and how the database asks for it.
The user would have to seed the session somehow (maybe, stored in a
temp table?) with a secret value which would be translated into the
key directly on the database or by a 3rd party over a secure channel.
The structured approach doesn't appeal to me much though...
The temp table idea might not be so hot, since it's trivial for the
database admin to see data from other user's temp tables, and maybe we
don't want that in some cases. need to think about this some more...
merlin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
