<br>On Sunday, January 19, 2014, Sergio Lerner <<a href="mailto:sergiolerner@pentatek.com">sergiolerner@pentatek.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm working in a password hashing construction (RandMemoHash, see<br>
<a href="http://bitslog.wordpress.com/2013/12/31/strict-memory-hard-hash-functions/" target="_blank">http://bitslog.wordpress.com/2013/12/31/strict-memory-hard-hash-functions/</a>).<br>
<br>
I need the fastest possible crypto "hash" function, even if breaking<br>
pre-image resistance requires about 2^32 operations. Collision<br>
resistance is unimportant.<br>
</blockquote><div><br></div><div> Interesting, you are looking for a hash function that does not lend itself to GPU hardware and other common cost effective attacks inside of a time window you consider safe.  Bitcoin hardware attack safe.... </div>
<div><br></div>In other threads a strategy like this would be suspect as an NSA ploy to establish a process into general use that they can attack but others not.  They could sit on some insight to their advantage while others could not play.  Since one validation is speed matching against internet latency... That seems ephemeral and or subject to attack. <div>
<br></div><div>I did note a comment in the paper about access and cache. N-way associative cache, cache size aware compilers, speculative execution etc could confound or confuse this goal as could memory technology. </div>
<div><br></div><div>I am tempted to coin a phrase: "Put a best if used before date on this strategy".</div><div><div><br></div><div><br></div></div><br><br>-- <br>I be mobile, excuse my tipping!<br>