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

On Fri, Apr 04, 2008 at 12:06:03AM +0200, Svenne Krap wrote:
> Sam Mason wrote:
> >Are you a cryptanalyst and are you sure that this doesn't actually make
> >things worse?  I'm sure it gives you a warm fuzzy feeling that it's
> >*got* to be better, but unless someone has done some hard maths I'm not
> >sure how you can be so sure.
> 
> No sadly I am no cryptoanalyst.

Neither am I.  I'm not sure if my comment came across right though..

> >Why not just use SHA-512, you get many more quality bits that way.
> >  
> I would, if it was available in core.

I'm still not sure why being in core is so special.

> >>I would drop md5 totally and use sha1 and ripemd-160 if possible.. but 
> >>currently i use only md5 as it is the only available one..  Loading 
> >>pgcrypto is overkill for something as simple as hash-functions.
> >>    
> >Sounds like a good reason for moving the current md5 function out into
> >pgcrypto as well! :)
> 
> I am not sure how I am to understand that comment. But again I am just a 
> user...

Within (most? larger anyway) software projects there's a big tension
between adding features that are directly useful to users, versus
providing tools that can be used to do more powerful things.  Modularity
and abstractions are about the only tools we have of taming complexity,
without them codebases become impossibly convoluted and difficult
to understand or modify.  The module system in PG is part of this,
it allows various parts of the code to be separated off (reasonably
cleanly) allowing the rest of PG to be modified without too much concern
of unrelated breakage.

Lets see how much flack I get for that! :)

> >I take it your threat model doesn't include the attacker logging
> >incoming queries to look for the clear-text password.
> 
> No it doesn't, I am mostly concerned with the grab and run scenario.

OK, this sort of thing is very application specific.

I have a feeling that my comments before came across a bit harshly,
sorry if they did.

> I am still convinced having more (and better) hash-functions in core is 
> a gain for some users.

Yes, having more functionality in the code is always better for users!
But the down side is that the rest of the software changes more slowly.
I.e. a lot of the correctness/features/performance improvements that
have been happening recently probably wouldn't have happened if all the
code that's in the various modules was in core.

> And it is fairly un-intrusive as the hash functions are well-defined and 
> never going to change (new ones can be added and old ones deleted, but 
> SHA256 for example will never change).

That's the sort of engineering problem I'm very bad at dealing with, I'm
more interested in the computer science parts.

> I think I will drop the issue as I cannot present formal proof of my 
> case, sorry to have wasted your time.

Sorry, that wasn't the intention of my mail---I just enjoy the formal
bits.  I think they can be pretty beautiful, but most of the time
they're irrelevant.

 Sam