From: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-performance@postgresql.org, Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: function body actors (was: viewing source code)
Date: Fri, 21 Dec 2007 11:48:26 -0500
Message-ID: <20071221164826.GI10918@crankycanuck.ca> (raw)
In-Reply-To: <26811.1198215605@sss.pgh.pa.us>
References: <b42b73150712202109u26d05d01q4f1b8be8d29f763c@mail.gmail.com>
<26811.1198215605@sss.pgh.pa.us>
On Fri, Dec 21, 2007 at 12:40:05AM -0500, Tom Lane wrote:
> 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).
It is. I'm not a security expert, but I've been spending some time
listening to some of them lately. The fundamental problem with a system
that stores the keys online in the same repository is not just its potential
for compromise, but its brittle failure mode: once the key is recovered,
you're hosed. And there's no outside check of key validity, which means
attackers have a nicely-contained target to hit.
> 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, one thing you could do with the proposal is build a PKCS#11 actor,
that could talk to an HSM. Not everyone needs HSMs, of course, but they do
make online key storage much less risky (because correctly designed ones
make key recovery practically impossible). So the mechanism can be made
effectively secure even for very strong cryptographic uses.
Weaker cases might use a two-level key approach, with a "data-signing key"
online all the time to do the basic encryption and validation, but a
key-signing key that is always offline or otherwise unavailable from within
the system. The key signing key only authenticates (and doesn't encrypt)
the data signing key. You could use a different actor for this, to provide
an interface to one-way functions or something. This gives you a way to
revoke a data-signing key. You couldn't protect already compromised data
this way, but at least you could prevent new disclosures.
Yes, I'm being hand-wavy now, but I can at least see how these different
approaches are possible under the suggestion, so it seems like a possibly
fruitful avenue to explore. The more I think about it, actually, the more I
like it.
A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ajs@crankycanuck.ca, pgsql-hackers@postgresql.org
Subject: Re: function body actors (was: viewing source code)
In-Reply-To: <20071221164826.GI10918@crankycanuck.ca>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox