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  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: Mon, 27 Jul 2015 14:02:20 -0700
From: Bill Cox <waywardgeek@...il.com>
To: John Tromp <john.tromp@...il.com>
Cc: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>, 
	"cryptography@...zdowd.com" <cryptography@...zdowd.com>
Subject: Re: [Cryptography] [OT] Improvement to Momentum PoW

On Mon, Jul 27, 2015 at 12:46 PM, John Tromp <john.tromp@...il.com> wrote:

> On Mon, Jul 27, 2015 at 2:29 PM, Bill Cox <waywardgeek@...il.com> wrote:
> > A problem with Momentum as currently implemented is that it can be run
> with
> > reduced memory, enabling efficient GPU attacks.
>
> Dave Andersen's latest remarks on his GPU code:
> https://bitcointalk.org/index.php?topic=826901.msg11944049#msg11944049
> You can ask him what he thinks is a faster implementation.
>
> Fore reduced memory, you can find all collisions in 8MB,
> using Cuckoo Cycle's algorithm for finding 2 cycles in bipartite graphs.
>
> >  I think we can get around
> > this problem simply by changing the parameters it uses.
>
> > If instead, we run with n == 26, and Hb's output also being 26 bits,
> then we
> > get around 2^26 collisions.
>
> To me, that's a completely different beast.
> I would no longer call that Momentum...
>
> -John
>

Well, it certainly seems different, at least in terms of optimizations and
attacks.  With input/output of Hb set to the same width, I _think_ it is
more GPU resistant.  I could be wrong.  I think we can not compute the
collisions efficiently in less than around 2^27 bytes, though there's the
obvious TMTO option, as usual in Momentum.

If this works as I think it does, without any attacks I'm missing, then I
would prefer this version, since it forces an ASIC to use more memory.  I
think the main ASIC defense for Momentum is total memory bandwidth.  The
latency defense is overcome with buffered radix-sort, but the data still
has to be written and read once.

Bill

Content of type "text/html" skipped

Powered by blists - more mailing lists