<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 3, 2014 at 8:15 AM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Oct 2, 2014, at 10:37 PM, Sandy Harris <<a href="mailto:sandyinchina@gmail.com">sandyinchina@gmail.com</a>> wrote:<br>
> There has been a lot of work on parallelizable hashing. Web search for<br>
> "tree hashing" will turn up much of it. <br></span></blockquote><div>...... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Keep in mind that "parallelizable" is often taken to mean "linear in the number of available processors".  No tree algorithm is "parallelizable" in this sense - it has a logarithmic delay to roll up the results.<br></blockquote><div><br></div><div>Minor point that should not be ignored. </div><div><br></div><div>To a programmer a good hash table is not the same as a good crypto hash.</div><div>A programmer simply wants a fast lookup with a minimum miss, collision.</div><div>Most programmers do not care if a collision is moderately easy to  fabricate</div><div>because they want to get close enough not exactly and will walk their way to</div><div>the desired data (short walk).</div><div><br></div><div>Crypto hashes need to be nearly impossible to generate by altering the data</div><div>input and spoofing a match. </div><div><br></div><div>Thus a fast hash for a Google webpage lookup is not the same design need as a fast hash</div><div>for Google data that should be kept secret and private. </div></div><div><br></div>-- <br><div dir="ltr">  T o m    M i t c h e l l</div>
</div></div>