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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
