[messaging] Peerio

[Watson Ladd]

On Fri, Jan 16, 2015 at 4:07 PM, Joseph Bonneau <jbonneau at gmail.com> wrote:
>
>
> 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
>> > 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
> Messaging at moderncrypto.org
> 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