From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sha1, sha2 functions into core? |
Date: | 2011-08-12 12:02:03 |
Message-ID: | CACMqXCL+4gekxhF7mhwUuxn5RsuVkpUe0+Ax1tN14z5Y0Eq8Gg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 11, 2011 at 5:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> On Wed, Aug 10, 2011 at 9:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> ... which this approach would create, because digest() isn't restricted
>>> to just those algorithms. I think it'd be better to just invent two
>>> new functions, which also avoids issues for applications that currently
>>> expect the digest functions to be installed in pgcrypto's schema.
>
>> I would suggest digest() with fixed list of algorithms: md5, sha1, sha2.
>
>> The uncommon/obsolete algorithms that can be used
>> from digest() if compiled with openssl, are not something we
>> need to worry over. In fact we have never "supported" them,
>> as no testing has been done.
>
> Hmm ... they may be untested by us, but I feel sure that if we remove
> that functionality from pgcrypto, *somebody* is gonna complain.
Well, if you are worried about that, you can duplicate current
pgcrypto behaviour - if postgres is compiled against openssl,
you get whatever algorithms are available in that particular
version of openssl.
My point was that giving such open-ended list of algorithms
was bad idea, but there is no problem keeping old behaviour.
> I don't see anything much wrong with sha1(bytea/text) -> bytea.
> There's no law that says it has to work exactly like md5() does.
The problem is that list of must-have algorithms is getting
quite long: md5, sha1, sha224, sha256, sha384, sha512,
+ at least 4 from upcoming sha3.
Another problem is that generic hashes are bad way for storing passwords
- identical passwords will look identical, and its easy to brute-force
passwords as the algorithms are very fast.
So the question is: is there actual *good* reason add each algorithm separately,
without uniform API to core functions?
If the user requests are about storing passwords, and we want to make
that easier, then we should import crypt() also, as that is the secure
way for password storage. Then the md5(), md5_b() plus bunch of
sha-s will look silly.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-08-12 12:14:05 | Re: our buffer replacement strategy is kind of lame |
Previous Message | Simon Riggs | 2011-08-12 11:57:41 | Re: our buffer replacement strategy is kind of lame |