On Fri, Jan 16, 2015 at 4:07 PM, Joseph Bonneau <[email protected]> wrote: > > > On Fri, Jan 16, 2015 at 6:40 PM, Trevor Perrin <[email protected]> wrote: >> >> On Wed, Jan 14, 2015 at 11:02 PM, Mike Hearn <[email protected]> wrote: >> > My big question (sorry Nadim, if this has been addressed before as part >> > of >> > the MiniLock discussions) is what stops passphrases being brute forced. >> > It >> > 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 [1] >> it suggests one for you (7 words from a ~16 bit list = ~112 bits >> entropy). > > > 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.
It's important to note that the attacks are parallel: I can get everyone using "Bob is my uncle" as a passphrase with one go. This is because minilock doesn't have a concept of user identity beyond the public key. This makes the attack much more productive than when attacking salted passwords. Furthermore, estimates of the entropy of any user entered text are likely to be wildly high. How many people are going to enter in the first line of Ozymandias, or Ulysses, or some other memorable book? We've done the experiment with brain wallets for bitcoin already: didn't look so good. > >> >> 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. With a slight change to the masks, could use local generation of password guesses to remove bandwidth barrier. What about FPGA? Sincerely, Watson Ladd > > oclHashcat has supported scrypt for a while but it is not really optimized > and the performance is poor. > > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
