In response to Thomas Kellerer <spam_eater@gmx.net>:
> Bill Moran wrote on 16.04.2009 22:20:
> >> I'm by far not an expert, but my naive attempt would be to store the the
> >> database files in an encrypted filesystem.
> >
> > That was the first suggestion when we started brainstorming ideas.
> > Unfortunately, it fails to protect us from the most likely attack
> > vector: SQL Injection/application layer bugs. In an SQL Injection
> > (for example) the fact that the filesystem is encrypted does zero
> > to protect the sensitive data.
>
> Which is something different than your statement
>
> >> The goal here is that if we're going to encrypt the data, it should
> >> be encrypted in such a way that if an attacker gets ahold of a dump
> >> of the database, they still can't access the data without the
> >> passphrases of the individuals who entered the data.
>
> which only talks about someone getting hold of the contents of the server's
> harddisk.
Not really. You're making an assumption that a pg_dump can only be
run on the server itself. Let's chalk this up to miscommunication
and allow me to rephrase:
The data needs to be encrypted in such a way that if an attacker can
get an offline copy of the data by any means, they have no greater
access to the data that they would if they used the application to
access it.
I already have that using PKI. Again, it seems that I left too many
details out of my description of the problem. See my post in
response to Steve Atkins for a more detailed description of the
problem, and I apologize for being too vague the first go-round.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/