<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jul 3, 2012, at 5:50 PM, PJ Eby &lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Menlo; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">Otherwise, we will have this exact same problem all over again when the replacement "secure" hash is disabled by a newer version of FIPS.</span></blockquote></div><br><div>Or, you know, somebody could maintain the dang software and automate the process of producing these hashes. &nbsp;I am slightly baffled by the tone of this thread, like the hash algorithm needs to be set in stone forever. &nbsp;There's a reason that most software treats hashes as pluggable: new algorithms come out every few years, you have to <i>expect</i>&nbsp;that your choice will be obsoleted for some reason (not necessarily just security!) in the future. &nbsp;Granted, there's no real security in this case, but why <i>not</i>&nbsp;use a hash algorithm with less probability of collision?</div><div><br></div><div>-glyph</div></body></html>