Re: sha1, sha2 functions into core?

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: sha1, sha2 functions into core?
Дата
Msg-id CACMqXCLWQS_fovCgj1EbFtmX60_f=DLT1CTvke8JdSNrR5cfBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: sha1, sha2 functions into core?  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: sha1, sha2 functions into core?
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav