<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 2, 2015 at 9:56 AM, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So it looks like it's saying "if we slow down the user by a factor of X,<br>
then we slow down an attacker by the same factor."<br>
<br>
The assumption here appears to be that there is no speedup for an<br>
attacker that is better than brute force.  If an attacker has some<br>
clever precomputation, or a way to reuse intermediate results<br>
efficiently, it seems like the slowdown for the attacker may be a<br>
smaller factor than the slowdown for the user, unfortunately.<br></blockquote><div><br></div><div style="font-size:12.8000001907349px">If you're salting the hash (basically, if you're doing password-based decryption of a private key file instead of password-based re-derivation of the private key), then there should be no effective precomputation as long as the hash is cryptographically secure.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">If you can't salt, then rainbow tables are a possibility. But iterating the same hash function still makes rainbow tables linearly more expensive to compute.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">As <span class="">dkg</span> said, this is just a linear numbers game, but I believe that's the worst case scenario. If you take N times longer to hash on the client side, you should always be able to slow the attacker down by at least a factor of N.</div><div style="font-size:12.8000001907349px"><br></div><div><span style="font-size:12.8000001907349px">Using a memory-hard function, or some other function designed to be difficult to implement in hardware, can slow some attackers down by a greater factor if it prevents them from building hardware as cheaply. As Taylor said there isn't a definitive paper on this yet as far as I know, though there are quite a few papers arising from the password-hashing competition with different design approaches, threat models, terminology, etc.</span> Hopefully we'll settle on a model eventually which can give simpler "bits of security" estimates as Nadim asked for.</div></div></div></div>