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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings