Message-ID: <CAMtf1HtBUvoFWQZjDem7ZzP9s5pc=DrQ=yO++OiQ_xCN624zhQ@mail.gmail.com>
Date: Thu, 7 Aug 2014 17:15:28 +0800
From: Ben Harris <ben@...rr.is>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Tradeoff cryptanalysis of password hashing schemes

Thanks Dimitry,

Page 26 just needs to be updated then - it says "Consider vertices [AB0]...
where each letter has k bits" suggesting that A and B are k bits each - not
that C is k bits.


On 7 August 2014 17:10, Dmitry Khovratovich <khovratovich@...il.com> wrote:

> Hi Ben,
>
> the following points are important:
>  - A, C, *, 0 are all k-bit values. k<n/3, and for the attack being
> efficient k>2.
>  - [**0] takes 2^(n-k) storage per level as you store everything that ends
> with k zeros.
>
> The example in presentation has |A| = |C| = 1, and |B|=2. Such small
> values are for the ease of understanding, but not for the efficiency. I
> attach the picture in the higher resolution. The red indices are those
> precomputed for the next level.
>
> Best regards,
> Dmitry
>
>
> On Thu, Aug 7, 2014 at 1:19 AM, Ben Harris <ben@...rr.is> wrote:
>
>> Just getting my head around the Catena one.
>>
>> Storing [**0] takes 2^2k storage per level? (presentation says 2^(n-k))
>> And the [*B*] takes 2^(n-k) storage
>> So L*2^2k + 2^(n-k) storage all up.
>>
>> Computing each [*B*] at level 0 takes 2^(n-2k) operations from each 2^k
>> [*B0]. total 2^(n-k) operations? (presentation says 2^2k)
>> Computing each [*^B*] at level 1 is more complicated because we don't
>> always have what we need.
>>
>> At level 1, for the A = 1, B = 1, and len(C) = 2 (the example in the
>> presentation). For the 2^(n-k) = 2^(4-1) = 8 [*^B*] we have
>> [00 1 0] - h( h([00 0 0] + [1 0 00]) + [0 1 00]) = 2 hashes
>> [00 1 1] - h([00 1 0] + [1 1 00]) - 1 hash
>> [01 1 0] - h([01 0 1] + [0 1 10]) - but [01 0 1] is h([01 0 0] + [1 0
>> 10]) and I don't have [1 0 10] it takes 2 hashes from [1 0 00]
>> [01 1 1] - 1 hash from previous
>> [10 1 0] - h([10 0 1] + [0 1 10]) -  again, I don't have [10 0 1]?
>> [10 1 1] - 1 hash from previous
>> [11 1 0] - again, we are missing something
>> [11 1 1] - 1 hash from previous
>>
>> These missing dependencies become exponential at level 2+.
>>
>> So there are three bits I'm getting a bit stuck on:
>>   - Storage per level
>>   - Operations for level 0
>>   - Missing dependencies at level 1
>>
>> Maybe I'm just misreading the slides and needed to see the talk?
>>
>>
>> On 7 August 2014 05:10, Marcos Simplicio <mjunior@...c.usp.br> wrote:
>>
>>> Hi, all.
>>>
>>> Very interesting analysis! We noticed the same attack venue described in
>>> slide 47 for Lyra2 some time ago, so we provided and evaluated a simple
>>> fix in the version provided in our website (http://lyra-kdf.net/, see
>>> section 5.1.2.3 of the specification). I'm not sure how the tradeoffs
>>> table is affected by this fix, but the costs are likely to grow (at
>>> least that was my impression by crossing your results with our
>>> preliminary analysis).
>>>
>>> BTW, the document in our website is being continuously updated as new
>>> tests are performed, so we expect to introduce this and possibly other
>>> tweaks in the corresponding phase of the PHC. We are still evaluating
>>> the "possible extensions" mentioned in the original submission, for
>>> example.
>>>
>>> BR,
>>>
>>> Marcos.
>>>
>>> On 06-Aug-14 14:31, Dmitry Khovratovich wrote:
>>> > Hi all,
>>> >
>>> > here is the link to the slides of the talk I have just given at
>>> > PasswordsCon'14. It investigates time-memory tradeoffs for PHC
>>> candidates
>>> > Catena, Lyra2, and Argon, and estimates the energy cost per password
>>> on an
>>> > optimal ASIC implementation with full or reduced memory.
>>> >
>>> > https://www.cryptolux.org/images/5/57/Tradeoffs.pdf
>>> >
>>> > Additional comment: It is a standard practice in the crypto community
>>> to
>>> > give explicit security claims for the recommended parameter sets so
>>> that
>>> > cryptanalysts could easily identify the primary targets. Many PHC
>>> > candidates do not follow this rule by not only missing these claims but
>>> > also concealing the recommended parameters. As a result, cryptanalysts
>>> like
>>> > me spend valuable time attacking wrong sets or spreading the attention
>>> over
>>> > multiple targets.
>>> >
>>> > Remember: third-party cryptanalysis increases the confidence in your
>>> > design, not decreases it (unless it is badly broken). Analysis of a
>>> 5%-part
>>> > of your submission (one of 20 possible parameter sets) is little better
>>> > than no analysis at all. It is also worth mentioning that to make fair
>>> > comparison of candidates, benchmarks and performance discussion in
>>> general
>>> > should cover recommended parameter sets only.
>>> >
>>>
>>
>>
>
>
> --
> Best regards,
> Dmitry Khovratovich
>

Content of type "text/html" skipped

Powered by blists - more mailing lists