phc-discussions - Re: [PHC] Panel: Please require the finalists to help with benchmarks

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: Fri, 3 Apr 2015 17:22:53 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Panel: Please require the finalists to help with benchmarks

On Fri, Apr 03, 2015 at 01:34:11PM +0000, Gregory Maxwell wrote:
> If I must. I wasn't going to respond on Bitcoin things-- they're
> largely out of scope, for this list (for reasons I'll explain now
> below).

Thank you for responding.  I think at least knowing that those things
are "largely out of scope" is helpful to us.

> Some people, like John Tromp, have been exploring the space of other
> kinds of POW functions that achieve properties like using memory
> hardness while minimizing the harm against other considerations here;
> but this is specialized work and heads off in a very different
> direction than PHC. (I have doubts about how worthwhile those efforts
> are either, but at least they're done with a careful mind to the
> application requirements and tradeoffs by someone who understands
> them).

FWIW, here's an attempt at an asymmetric memory-hard PoW by Bram Cohen,
the inventor of BitTorrent:

http://bramcohen.com/2014/11/24/a-crazy-idea-for-proofs-of-work

He's also been interested in what we're doing here in PHC:

http://bramcohen.com/2014/11/18/a-mode-for-password-hashing

Maybe some hybrid approach would work best for cryptocurrencies that
want to encourage CPU mining: use a memory-hard PHC candidate (or the
like) at fairly low settings (but not to the point of the area cost
being negligible) as a building block in an asymmetric memory-hard PoW,
like what Bram described?  For example, a 2 MB symmetric hash expanded
to a 2 GB asymmetric PoW.  That way, possible flaws of the asymmetric
memory-hard PoW would be partially mitigated by use of the likely better
understood symmetric memory-hard hash.

Alexander