On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote:
> Marko Kreen <marko@l-t.ee> writes:
> > And if you decide to do it, please make them all STRICT too,
> > _except_ encrypt/decrypt functions. Thats an additional change
> > I have in the air for pgcrypto.sql.in.
>
> > As for the encrypt/decrypt functions, I am increasingly
> > favouring throwing error in case of NULL arguments.
>
> 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.
With PGP, this is part of functionality - there will
be SHA1 attached to data. Now, encrypt() should throw
error just for symmetricity and to force user handle the
'no data' case externally.
On the other hand, all this is corner-case protection
from someone who has already write-access to table.
This could be also solved with documenting that user must
specifically think how to handle 'success' from null values.
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.
Do you object to non-strict crypt() too?
--
marko