Re: sha1, sha2 functions into core?

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sha1, sha2 functions into core?
Date: 2012-08-15 11:42:13
Message-ID: CACMqXCLWQS_fovCgj1EbFtmX60_f=DLT1CTvke8JdSNrR5cfBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-08-15 13:39:38 Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Previous Message Peter Geoghegan 2012-08-15 10:51:54 Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav