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: Fri, 3 Apr 2015 17:17:37 +0200
From: Dmitry Khovratovich <>
Subject: Re: [PHC] Panel: Please require the finalists to help with benchmarks

Tromp's construction was broken by David Andersen

Cohen's idea is collision search; it is known to be performed
memoryless with little penalty

On 4/3/15, Solar Designer <> wrote:
> 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:
> He's also been interested in what we're doing here in PHC:
> 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

Best regards,
Dmitry Khovratovich

Powered by blists - more mailing lists