Re: sha1, sha2 functions into core? - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: sha1, sha2 functions into core?
Date
Msg-id CACMqXCLWQS_fovCgj1EbFtmX60_f=DLT1CTvke8JdSNrR5cfBQ@mail.gmail.com
Whole thread Raw
In response to Re: sha1, sha2 functions into core?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: sha1, sha2 functions into core?
List pgsql-hackers
On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Is there a TODO here?

There is still open ToDecide here:

1) Status quo - md5() in core, everything else in pgcrypto

2) Start moving other hashes as separate functions into core: eg. sha1()
Problems:
- sha1 will be obsolete soon, like md5
- many newer hashes: sha2 family, upcoming sha3 family
- hex vs. binary api issue - hex-by-default in not good when you actually need cryptographic hash (eg. indexes)
- does not solve the password storage problem.

3) Move digest() from pgcrypto into core, with same api.
Problems:
- does not solve the password storage problem.

4) Move both digest() and crypt() into core, with same api.


Password problem - the cryptographic hashes are meant
for universal usage, thus they need to be usable even
on megabytes of data.  This means they are easily
bruteforceable, when the amount of data is microscopic
(1..16 chars).  Also they are unsalted, thus making
cracking even easier.  crypt() is better api for passwords.

So when the main need to have hashes is password
storage, then 2) is bad choice.

My vote: 4), 1)

-- 
marko



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav