phc-discussions - Re: [PHC] Bandwidth hardened algorithms?

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-next>] [day] [month] [year] [list]

Date: Tue, 14 Jul 2015 05:06:04 +0100
From: denis bider <pwhashing@...isbider.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Bandwidth hardened algorithms?

> So the problem addressed in this discussion is how to defend against
> ASIC mining.  You have to find something that a CPU and/or a GPU can
> do well that an ASIC wont do much better.  Requiring a lot of memory
> and serial computation of the data you use to fill it makes the
> algorithm memory-hard, but if you fill memory slowly due to slow
> cryptographic hash computations, and ASIC will beat you on speed.
> This seems to be where we are with current algorithms, IMO.

And I think the solution to that is going to be WebAssembly.

Generate a bunch of relatively random, yet still application-like, and platform-independent code. Execute it in WebAssembly sandbox. See who runs it faster, custom ASIC or CPU.

In 15 years or so, WebAssembly is going to be the world's universal  bytecode, and probably the most important usage case for which to  optimize a CPU. If custom ASIC is *substantially* faster - note that slightly faster isn't worth it, given you can spend $1 million on a lot of CPUs - then you've just been given a free breakthrough for future design of CPUs.

Taking another route - ASICs can also be discouraged at protocol level if you (1) hardcode obsolescence after e.g. 1 year into every released reference peer implementation, so all peers MUST upgrade, and (2) change proof of work significantly on an annual basis as a precaution, whether there is an apparent ASIC there or not. If that's done regularly enough, your main worry is whether your cycle is fast enough to make ASICs non-worthwhile.

But the largest payoff can be gained in a few months, so ASICs may still be worth it for a valuable currency if their development cycle is fast. And there's a tradeoff to mandated obsolescence: the faster your upgrade cycle is, the more vulnerable your currency is to any vacuum caused by collapse of maintainer structure. It becomes more reliant on a centralized authority as catalyst of peer agreement (and then you might as well not have a peer to peer currency).

Content of type "text/html" skipped