lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 01 Oct 2014 18:19:17 -0300
From: Marcos Simplicio <>
Subject: Re: [PHC] Design Rationale and Security Analysis of PHC candidates

OK, it is rather a matter of semantics then :)

OTOH, I may be shooting myself in the foot here, but I'm not sure the
attack you describe is actually better than what we (partially)
describe. More precisely (and I may very well have misunderstood
something from your slides): in Lemma 1, we describe an attack with no
penalty during the Setup phase when the memory usage is 1/2, while in
your case the attack penalty is described as "1.5" in (which I assume
means "50% slower") in slide 48. Did I miss something?

For the Wandering phase, we indeed consider a scenario with 50% of the
memory usage to show how badly the strategy being discussed ("store
ahead") scales. Now that I think about it, that was misleading, since it
was never intended as a through analysis for such 50% memory usage.
Anyhow, that was our fault, so you do have the right to say that your
attack is better than what we provided in the documentation.

Anyway, again: that was a great analysis and we are taking those
considerations into account in our own trade-off discussion. I believe
it should be placed into a context were the speed is also taken into
account, though, since if the user is willing to spend ~3.5 seconds
doing the password hashing (the time obtained by Bill in his benchmarks
for Argon), for example, then he/she would prefer using T around 5,
which, by design, leads to a much higher TMTO defense.



On 01-Oct-14 14:07, Dmitry Khovratovich wrote:
> Hi Marcos,
> thank you for the response!
> my understanding was that page 22 and Section 5.1.3 in
> contain some
> analysis of using less memory than intended. In particular, you describe
> how to use 1/2 of memory in the Setup phase (page 22) and in the Wandering
> phase (page 25).
> Maybe wording "claims" was too strong in my document, it would be better to
> say that there exist third-party results more efficient than the original
> analysis.
> I did not look into tweaks intentionally, I'd prefer to wait till they are
> approved by the committee.
> Best regards,
> Dmitry
> On Wed, Oct 1, 2014 at 6:43 PM, Marcos Simplicio <>
> wrote:
>> Hi.
>> I'm not sure whether "attacked" applies to the 'Tradeoff analysis" of
>> Lyra2: originally there were no claims on attacks involving half of the
>> memory usage, but only against a very low memory usage.
>> We do have such claims in the new version to be submitted (assuming
>> Lyra2 moves to the phase in which such tweaks are allowed), and the
>> attack venue described does not seem to be effective in that case.
>> Also, the "FPGA/ASIC defense" does not take into account all tweaks
>> described in the documentation, although I agree with "attacked" if you
>> consider only the basic design and ignores this part of the document.
>> Anyhow, very interesting analysis!
>> BR,
>> Marcos Simplicio
>> On 30-Sep-14 08:12, Dmitry Khovratovich wrote:
>>> We have prepared a small survey of the design rationale and security
>>> analysis of the PHC submissions. It should help the committee to evaluate
>>> the candidates and the community to see the status and potential
>> strengths
>>> and weaknesses of the candidates.
>>> We are welcome to any feedback. We plan to add further information to the
>>> tables, possibly in the spirit of Microsoft criteria.
>>> The permanent link is

Powered by blists - more mailing lists