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: Tue, 10 Dec 2013 20:07:40 +0100
From: Krisztián Pintér <>
Subject: Re: [PHC] blakerypt sequential memory-hard function (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.

> 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. further, after registering on pc, every login
from his phone takes a 100 seconds. 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.

> 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.

Powered by blists - more mailing lists