Jim C. Nasby wrote:
> On Tue, Oct 17, 2006 at 04:34:35PM +0300, Marko Kreen wrote:
>>> I'm not sure if anyone else needs something like it, but it allows us to
>>> transparently encrypt data directly in the tables. Minimum application
>>> changes ('select enc_key' at connection) - the main requirement when
>>> working on legacy code that needs to match todays security polices quickly.
>> Some want row-level access control, then your scheme would not be enough.
>>
>> Maybe it would be better to avoid combining the keys, instead have
>> hidden key in database and several user keys that grant access to that
>> key, thus you can revoke access from only some users.
>>
>> But one thing I suggest strongly - use PGP encryption instead
>> of old encrypt()/decrypt(). PGP hides the data much better,
>> espacially in case of lot of small data with same key.
>
> Better yet, allow the user to plug in encryption modules. Different
> people want different kinds of encryption. For example, I believe credit
> card companies require AES192.
As its really just a type wrapper around automatically calling
pgcrypto's encrypt/decrypt functions, this should be very easy to do.
I currently default it to 'bf' (blowfish) I can just make the type
creator have an additional parameter that takes any method recognized by
the crypto library.
Weslee