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: <20150403142253.GA26881@openwall.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ