Re: contrib/pgcrypto functions not IMMUTABLE?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marko Kreen <marko@l-t.ee>
Cc: Michael Fuhr <mike@fuhr.org>, Russell Smith <mr-russ@pws.com.au>, pgsql-hackers@postgresql.org
Date: 2005-07-03T16:57:54Z
Lists: pgsql-hackers
Marko Kreen <marko@l-t.ee> writes:
> On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
>> That doesn't seem like a good idea at all.  Why shouldn't an encryptable
>> value be NULL?  I think you should just make 'em strict.

> Well, I have mainly issues with decrypt part.  I'd like
> to say, if decrypt succeeds, whoever put the data there,
> had the key.  Existing decrypt() has a smell of it - there
> is 1/256 chance that data modification won't be detected.

And that has what to do with throwing an error on NULL input?

> As for the crypt() case, lets say you have a new user with
> hashed password field NULL.  In addition, you have client
> program that compares crypt() result with hashed field
> itself, in addition it handles NULL's as empty string.
> Result: it is possible to login with any password.
> Lots of assumptions but in eg. PHP case they are all filled.

A NULL password field is intended to have exactly that effect, no?

			regards, tom lane