jbonneau at gmail.com
Fri Jan 16 16:07:47 PST 2015
On Fri, Jan 16, 2015 at 6:40 PM, Trevor Perrin <trevp at trevp.net> wrote:
> On Wed, Jan 14, 2015 at 11:02 PM, Mike Hearn <mike at plan99.net> wrote:
> > My big question (sorry Nadim, if this has been addressed before as part
> > the MiniLock discussions) is what stops passphrases being brute forced.
> > seems from the spec that the passphrase == private key and public key is
> > then derived from that, in the usual ECC manner.
> In miniLock, if you try a passphrase that fails a strength check 
> it suggests one for you (7 words from a ~16 bit list = ~112 bits
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).
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.
> More and more systems are using scrypt for password hashing. Does
> anyone know the state-of-the-art in scrypt cracking?
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.
oclHashcat has supported scrypt for a while but it is not really optimized
and the performance is poor.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging