phc-discussions - Re: [PHC] Transforming hash to different cost setting

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]

Message-ID: <20140323142553.GB28781@openwall.com>
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