Re: [GENERAL] SHA1 on postgres 8.3 - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: [GENERAL] SHA1 on postgres 8.3
Date
Msg-id e51f66da0801290006k2f1f926cle522ddd657fd06e@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] SHA1 on postgres 8.3  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
On 1/28/08, Greg Sabino Mullane <greg@turnstep.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


pgsql-hackers by date:

Previous
From: Hans-Juergen Schoenig
Date:
Subject: Re: autonomous transactions
Next
From: Florian Weimer
Date:
Subject: Re: [GENERAL] SHA1 on postgres 8.3