phc-discussions - Re: [PHC] blakerypt sequential memory-hard function

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1312102011030.9087@debian>
Date: Tue, 10 Dec 2013 20:20:13 +0100 (CET)
From: Stefan.Lucks@...-weimar.de
To: discussions@...sword-hashing.net
Subject: Re: [PHC] blakerypt sequential memory-hard function

On Tue, 10 Dec 2013, Krisztián Pintér wrote:

> Stefan.Lucks@...-weimar.de (at Tuesday, December 10, 2013, 7:33:49 PM):
>
>> Well, theoretically you get two additional bits of security, no more. That
>> is quite marginal.
>
> are you sure about that? the way i read it is 2 bits plus the
> uncertainty of the running time. if the true time is 100ms, but the
> attacker sets the stopping condition to 1600ms, we have a factor of
> 16, a 4 bit additional strengthening. still not a game changer though.

Where do you think the two bits come from? It is the uncertainity of the 
running time (actually, the number of iterations).

The two bits is for the adversaries best strategy to stop and continue. If 
the true time is 100ms (or rather, X iterations) and the adversary only 
stops at 1600ms (at 16*X iterations), the adversary has chosen a bad 
strategy.

>> That is exactly the benefit of Boyen's paper. The user doesn't set a
>> parameter, the user waits as long as she is willing to wait, and then
>> stops.
>
> this is exactly the design i'm against. the first time the user faces
> this, he will just sit and think, hm, how strong i want it to be?
> maybe now it is good? just a little bit more security for me. okay,
> click now. and then he will be extremely upset to find out that every
> login takes 7 seconds.

By my personal experience, 7 seconds the user has chosen for herself will 
upset her *much* less than, say, 3.5 seconds chosen by the sysadmin.

> further, after registering on pc, every login from his phone takes a 100 
> seconds.

Why should it?

Usually, your password hash is running on the same server, whether you log 
in from a pc or a phone.

If the password hash function is executed on heterogenous systems, then, 
indeed, letting the user choose her time on a random system is bad design.

> no way you convince any commercial websites to use that method, instead 
> of offering a list of low end pc / high end pc / smartphone / tablet 
> presets.

And when I chose the "high end pc" option and later decide to log in from 
my smartphone? (Assuming the password hash is executed on my machine, not 
on the server, otherwise different presets don't make sense, anyway.)

>> A disadvantage is, of course, that the scheme is all about the time, and
>> not the memory usage.
>
> we don't want that in fact. memory should be based on what the
> hardware offers. with the caveats listed above.

Agreed!

------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--