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

From Svenne Krap
Subject Re: [GENERAL] SHA1 on postgres 8.3
Date
Msg-id 47F554CB.3020409@krap.dk
Whole thread Raw
In response to Re: [GENERAL] SHA1 on postgres 8.3  (Sam Mason <sam@samason.me.uk>)
Responses Re: [GENERAL] SHA1 on postgres 8.3  (Sam Mason <sam@samason.me.uk>)
List pgsql-hackers
Sam Mason wrote:<br /><blockquote cite="mid:20080403182304.GK6870@frubble.xen.chris-lamb.co.uk"
id="mid_20080403182304_GK6870_frubble_xen_chris-lamb_co_uk"type="cite"><pre wrap="">Are you a cryptanalyst and are you
surethat 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. </pre></blockquote> No sadly I am no cryptoanalyst. <br /><blockquote
cite="mid:20080403182304.GK6870@frubble.xen.chris-lamb.co.uk"
id="mid_20080403182304_GK6870_frubble_xen_chris-lamb_co_uk"type="cite"><pre wrap="">
 
Why not just use SHA-512, you get many more quality bits that way. </pre></blockquote> I would, if it was available in
core.<br/><blockquote cite="mid:20080403182304.GK6870@frubble.xen.chris-lamb.co.uk"
id="mid_20080403182304_GK6870_frubble_xen_chris-lamb_co_uk"type="cite"><pre wrap=""> </pre><blockquote
id="StationeryCiteGenerated_2"type="cite"><pre wrap="">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.   </pre></blockquote><pre wrap="">Sounds like a good
reasonfor moving the current md5 function out into
 
pgcrypto as well! :) </pre></blockquote> I am not sure how I am to understand that comment. But again I am just a
user...<br/><blockquote cite="mid:20080403182304.GK6870@frubble.xen.chris-lamb.co.uk"
id="mid_20080403182304_GK6870_frubble_xen_chris-lamb_co_uk"type="cite"><blockquote id="StationeryCiteGenerated_3"
type="cite"><prewrap="">* I prepend the id and the username to guard users with weak passwords 
 
against known hashvalues (rainbow tables) should the box ever get 
comprised ...    </pre></blockquote><pre wrap="">
I take it your threat model doesn't include the attacker logging
incoming queries to look for the clear-text password. </pre></blockquote> No it doesn't, I am mostly concerned with the
graband run scenario. <br /><br /> I am still convinced having more (and better) hash-functions in core is a gain for
someusers. <br /><br /> And it is fairly un-intrusive as the hash functions are well-defined and never going to change
(newones can be added and old ones deleted, but SHA256 for example will never change). <br /><br /> I think I will drop
theissue as I cannot present formal proof of my case, sorry to have wasted your time.<br /><br /> Svenne  

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Row estimation for "var <> const" and for "NOT (...)" queries
Next
From: Alvaro Herrera
Date:
Subject: Re: psql \G command -- send query and output using extended format