Re: [GENERAL] SHA1 on postgres 8.3

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] SHA1 on postgres 8.3
Date: 2008-01-29 08:06:45
Message-ID: e51f66da0801290006k2f1f926cle522ddd657fd06e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 1/28/08, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
> > I am not thrilled about moving _some_ of pgcrypto into the backend ---
> > pgcrypto right now seems well designed and if we pull part of it out it
> > seems it will be less clear than what we have now. Perhaps we just need
> > to document that md5() isn't for general use and some function in
> > pgcrypto should be used instead?

I don't think docs will help much. The md5() has broken the
policy of "all crypto in external module" so I'm now thinking
we should just bite the bullet and add digest() to core.

Exctracting the part from pgcrypto is no-brainer, the hashes have
very thin wrapper around them, only thing common with rest of
pgcrypto is error handling, which hashes use the least.

Only thing that needs minor thought is that it would be nice
to access hashes from external module - that means exporting
the find_digest() function to it. Which should be no problem.

> I think looking at this as putting some of pg_crypto into core is looking
> at this the wrong way. We are never going to put the whole thing into
> core given the current state of cryptography laws, as obviously the
> current status of giving users md5() and nothing else is not ideal. What
> we're looking for is a middle ground. It seems to me we've narrowed
> it down to two questions:
>
> 1) Does sha1(), or other hashing algorithms risk running afoul of
> cryptography regulations?
>
> I'm 100% sure that sha1() itself is not a problem (it's even a PHP builtin,
> and good luck finding a box these days wihout that monstrosity installed).
> I highly doubt any of the rest (SHA*, HMAC, etc.) are a problem either:
> we're doing a one-way hash, not encrypting data. But common sense and
> cryptography have seldom been seen together since the start of the cold war,
> so I'll hold my final judgement.
>
> 2) Which ones do we include?
>
> Putting sha1() seems a no-brainer, but as Joe points out, why not add all
> the rest in at the same time?

Considering we have DES and MD5 already, then how can SHA2 be
a problem when SHA1 isnt?

--
marko

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Florian Weimer 2008-01-29 08:10:13 Re: [GENERAL] SHA1 on postgres 8.3
Previous Message Marko Kreen 2008-01-29 07:45:04 Re: 8.3RC2 vs 8.2.6 testing results

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Weimer 2008-01-29 08:10:13 Re: [GENERAL] SHA1 on postgres 8.3
Previous Message Hans-Juergen Schoenig 2008-01-29 07:52:39 Re: autonomous transactions