On Dec 21, 2007 11:48 AM, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
> 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.
ISTM the main issue is how exactly the authenticated user interacts
with the actor to give it the information it needs to get the real
key. This is significant because we don't want to be boxed into an
actor implementation that doesn't allow that interaction. If simply
calling out via a function is enough (which, to be perfectly honest, I
don't know), then we can implement the actor system and let actor
implementations spring to life in contrib, pgfoundry, etc. as the
community presents them.
merlin
