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] [thread-next>] [day] [month] [year] [list]
Date: Sun, 23 Mar 2014 18:25:53 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Transforming hash to different cost setting

On Sat, Mar 22, 2014 at 10:44:11PM -0400, Bill Cox wrote:
> On Sat, Mar 22, 2014 at 6:02 PM, Solar Designer <solar@...nwall.com> wrote:
> > Just don't approximate area-time as "peak memory usage * time" for the
> > whole upgraded hash, because its memory usage drops back to zero on each
> > upgrade, whereas a never-upgraded hash's memory usage is monotonically
> > non-decreasing.  We need to compare the area below those "curves", but
> > they're of different shape, so we can't make conclusions on how the area
> > differs by looking only at the peak.
> >
> > Here are the numbers:
> >
> > http://thread.gmane.org/gmane.comp.security.phc/504/focus=639
> >
> > Alexander
> 
> I was afraid you were integrating the memory*time rather than just
> using peak memory * time.

I had considered that, yes, and I think it'd provide exactly the same
efficiency ratios (actual AT vs. potential AT) for the schemes we
discussed so far.  For schemes where memory usage grows linearly all the
time (ignoring the effect of caches for the sake of simplicity, as well
as because an ASIC attacker probably won't have them), the average
memory usage is half of peak.  For scrypt-like schemes, the average
memory usage is 3/4 of peak.  Either way, it's a constant factor that
applies to each upgrade granularity unit and that does not change with
number of upgrades, so it should not affect the ratios.

> It's probably a good thing there's not much time left in the PHC
> contest for testing out such ideas.  I'm way behind at work!

Yeah, but it's not as good for me because I intend to continue work on
escrypt anyway, whether PHC or not.

Alexander

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ