On Dec 21, 2007 12:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
> > On Dec 20, 2007 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 6: explain analyze is your friend

I have similar patch and it works. There is two isues:

* we missing column in pg_proc about state (not all procedures are
obfuscated), I solved it for plpgsl with using probin.
* decrypt is expensive on language handler level. Every session have
to do it again and again, better decrypt in system cache or somewhere
there.

Regards
Pavel Stehule

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Dec 21, 2007 3:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I have similar patch and it works. There is two isues:
>
> * we missing column in pg_proc about state (not all procedures are
> obfuscated), I solved it for plpgsl with using probin.

I was hoping to avoid making any catalog or other changes to support
encryption specifically. Maybe your patch stands on its own
merits...I missed the original discussion. Do you think the code you
wrote can be adapted to do other things besides encryption?

> * decrypt is expensive on language handler level. Every session have
> to do it again and again, better decrypt in system cache or somewhere
> there.

Doesn't bother me in the least...and caching unencrypted data is
scary. Also, aes256 is pretty fast for what it gives you and function
bodies are normally short. The real issue as I see it is where to
keep the key. How did you handle that?

merlin

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On 21/12/2007, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Dec 21, 2007 3:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> > I have similar patch and it works. There is two isues:
> >
> > * we missing column in pg_proc about state (not all procedures are
> > obfuscated), I solved it for plpgsl with using probin.
>
> I was hoping to avoid making any catalog or other changes to support
> encryption specifically. Maybe your patch stands on its own
> merits...I missed the original discussion. Do you think the code you
> wrote can be adapted to do other things besides encryption?
>

I don't know. It was fast hack that just works. It hat to do
obfuscation, and it do it well.

> > * decrypt is expensive on language handler level. Every session have
> > to do it again and again, better decrypt in system cache or somewhere
> > there.
>
> Doesn't bother me in the least...and caching unencrypted data is
> scary. Also, aes256 is pretty fast for what it gives you and function
> bodies are normally short. The real issue as I see it is where to
> keep the key. How did you handle that?
>
> merlin
>

Simply. I use for password some random plpgsql message text and
compile it. I though about GUC, and about storing password in
postgresql.conf. It's equal to protection level. We cannot protect
code on 100%. If you have admin or superuser account and if you know
some internal, you can simply get code.

http://blog.pgsql.cz/index.php?/arch....html#extended

sorry for czech desc

Pavel

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly