Re: Looking for advice on database encryption

If the purpose of encrypting the data is just to keep prying eyes from decerning what that data is then a simple encryption can be coded. something like adding 128 or 256, depending on the character set, to each of the chr(value) for each of the characters in the string should work just fine. You could also use a bitwise shift or xor to change the value of each character.

If the purpose of encryption is for financial or medica data transmission security, or something of a higher order, you may want to implement a stronger type of security such as SSL or PGP or some other type of public/private key process.

You could create a schema that contains views of the data with out the sensitive data and have the users use that schema for their needs, assumes that it basically used to view or report on the data.

Just some thoughts.

Michael Black

> Date: Thu, 16 Apr 2009 15:40:12 -0400
> From: wmoran(at)potentialtech(dot)com
> To: pgsql-general(at)postgresql(dot)org
> Subject: [GENERAL] Looking for advice on database encryption
>
>
> What are folks doing to protect sensitive data in their databases?
>
> We're running on the assumption that the _really_ sensitive data
> is too sensitive for us to just trust the front-end programs that
> connect to it.
>
> The decision coming down from on-high is that we need to encrypt
> certain fields. That's fine, looked at pgcrypto, but found
> the requirement to use pgp on the command line for key management
> to be a problem.
>
> So we're trying to implement the encryption in the front-end, but
> the problem we're having is searching on the encrypted fields. Since
> we have to decrypt each field to search on it, queries that previously
> took seconds now take minutes (or worse).
>
> We've tested a number of cryptographic accelerator products. In
> case nobody else has tried this, let me give away the ending: none
> that we've found are any faster than a typical server CPU.
>
> So, it's a pretty open-ended question, since we're still pretty open
> to different approaches, but how are others approaching this problem?
>
> 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.
>
> --
> Bill Moran
> http://www.potentialtech.com
> http://people.collaborativefusion.com/~wmoran/
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general