On Mon, 12 Apr 2004, Christopher Browne wrote:
> scott.marlowe@ihs.com ("scott.marlowe") wrote:
> > On Mon, 12 Apr 2004, Tom Lane wrote:
> >
> >> "scott.marlowe" <scott.marlowe@ihs.com> writes:
> >> > On Fri, 9 Apr 2004, Christopher Browne wrote:
> >> >> See the "pgcrypto" contrib module in the source tree.
> >> >>
> >> >> It is not typically compiled into what gets distributed with the
> >> >> typical Linux/BSD distribution because of the library dependencies
> >> >> that it forces in, as well as because the legalities surrounding the
> >> >> distribution of cryptographic software vary from country to country,
> >> >> making it potentially legally unsafe to ubiquitously include it.
> >>
> >> > I thought md5() was a built-in nowadays...
> >>
> >> Yeah, it is, but md5 is not considered cryptography because it is not
> >> reversible (you can't decrypt to get back what you put in). As such
> >> it's not restricted under US munitions law, nor anyone else's that
> >> I've heard of.
> >
> > True, but the original discussion, I believe, was on storing user
> > passwords etc... for which md5 is the preferred method...
>
> No, the original discussion was about encrypting fields in the
> database, so MD5 doesn't cut it.
OK, thanks. I think I got my threads cross-wired.
> Actually, for the purpose being pointed at, I would actually suggest
> that the Gentle User consider preferring that the database DOESN'T
> directly support encryption, because if it did, it would be tempting
> to pass encryption keys to the database, thereby COMPROMISING the
> security of the system.
I agree completely. There's a new italian law that says that everything
in a database that's personal data has to be encrypted, and there was
another discussion on that. Did you see that one go by? Seems the law
isn't real clear on where encryption / decryption or key holding should
take place.
