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.
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.
After all, suppose the database supports stored procedures of the
form:
encrypt(key, field)
and
decrypt(key, field)
Then an unscrupulous sysadmin type could replace them with alternative
stored procedures that add in a couple of inserts...
insert into nefarious_schema.keep_keys (id, key) values (nextval('my_keying'), key);
insert into nefarious_schema.keep_field (id, field) values (currval('my_keying'), field);
The data can only remain truly secure in the database if encryption
and decryption don't even take place there.
It is all well and nifty to throw encryption tools into the database,
but this example quite clearly demonstrates that this is not a recipe
for _improving_ security of the system...
--
"cbbrowne","@","ntlug.org"
http://www3.sympatico.ca/cbbrowne/crypto.html
"Computers double in speed every 18 months or so, so any "exponential
time" problem can be solved in linear time by waiting the requisite
number of months for the problem to become solvable in one month and
then starting the computation." -- pratt@Sunburn.Stanford.EDU
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
