<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 6:40 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Jan 14, 2015 at 11:02 PM, Mike Hearn <<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>> wrote:<br>
> My big question (sorry Nadim, if this has been addressed before as part of<br>
> the MiniLock discussions) is what stops passphrases being brute forced. It<br>
> seems from the spec that the passphrase == private key and public key is<br>
> then derived from that, in the usual ECC manner.<br>
<br>
<br>
</span>In miniLock, if you try a passphrase that fails a strength check [1]<br>
it suggests one for you (7 words from a ~16 bit list = ~112 bits<br>
entropy).<br></blockquote><div><br></div><div>Is there a design rationale for these choices? 112 bits is overkill for something users need to memorize (especially with 2^17 of stretching) and a 2^16 dictionary in my experience is vastly bigger than ideal (though we don't really have good research confirming this, it's just a hunch).</div><div><br></div><div>Personally I would say 70 bits plus 2^20 stretching is secure against any economically imaginable attacker and 60 bits plus 20 bits of stretching is probably secure against non state-level attackers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
More and more systems are using scrypt for password hashing.  Does<br>
anyone know the state-of-the-art in scrypt cracking?<br></blockquote><div> </div><div>The state of the art varies a lot based on the parameters you use with scrypt. The Litecoin community (and derivative altcoins) have pushed this quite a lot. Unfortunately the parameters in Litecoin (N=2^10) are pretty small so it's not clear how they would compare to the values you'd see miniLock or Peerio. But they seem to hit an upper limit of around 1MHz on GPUs. There are Litecoin-dedicated ASICs that are dramatically faster, but they would not work for password cracking easily because the data bus doesn't have the bandwidth to push millions of password guesses per second.</div><div><br></div><div>oclHashcat has supported scrypt for a while but it is not really optimized and the performance is poor. </div></div></div></div>