phc-discussions - Re: [Cryptography] [OT] Improvement to Momentum PoW

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: <CAOLP8p4B8RE1VtvxWtMYRmN06ygree-aAipjxXKB4tONtwBW3w@mail.gmail.com>
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