[cryptography] Scrypt hardware optimized miner

Solar Designer solar at openwall.com
Mon Jun 29 23:52:45 EDT 2015


On Mon, Jun 29, 2015 at 09:40:56AM +0200, Fabio Pietrosanti (naif) - lists wrote:
> Now that Scrypt has been used by cryptocurrency a new generation of
> hardware optimized miner (that can be converted to password-cracking)
> went out https://www.hashcoins.com/buy-scrypt-miners/ .

What's so new about this generation, and what makes you think it "can be
converted to password-cracking"?

It was already possible to buy an scrypt cryptocoin ASIC miner
supporting higher than Litecoin's N late last year:

https://twitter.com/dildog/status/540708538814050304

But that's not the only requirement for reuse for password cracking.
You also need the ASIC to support whatever value of r your hashes use
(for cryptocoins it's commonly r=1 and for password hashes and KDF use
it's commonly r=8) and, unless your scrypt hash is unlucky and happens
to start with lots of 0's, you need the ASIC to support other than only
a "less than target" check or have a high bandwidth interface.  Chances
are that existing scrypt cryptocoin ASICs are limited to r=1, can only
check "less than target", and use low bandwidth interfaces (sufficient
to report successful shares when pool-mining, but insufficient to
efficiently feed a stream of computed hashes to another system for
checking against the hashes being cracked... unless N is very high).

Aside from the likely show-stopper with r, with a high enough N that the
rate of computed hashes is very low (and would have been even lower on
CPU/GPU/FPGA?), these ASICs might be usable for password cracking.
I don't know if they can return the actual computed hash value to host or
not, but even if not they can probably be used to reject half of the
candidate passwords (and more for hashes that start with multiple zero
bits, accordingly) as long as you're cracking a known hash (can't do
this with KDF-only use of scrypt, where you need to obtain each derived
key to test it).

Someone might want to research this.

Another area for research is reuse of those ASICs for a custom password
hashing scheme or KDF (that would thus be a higher level scheme building
upon scrypt in a certain weird way to match the ASICs):

https://twitter.com/solardiz/status/610562741967933440

> The questions are:
> 
> a) Is scrypt always safe enough?

"Is it safe?"

http://www.imdb.com/title/tt0074860/quotes

> b) Which scrypt parameters should be tweaked in order to make it *much
> more* difficult to the hardware minire?

Just use scrypt as it's intended to be used.  The more memory you let it
use, the more costly it is to crack.

Also, avoid r=1.  Use r=8 as recommended in the scrypt paper.

> c) Is the approach of chaining multiple hashing systems (to require the
> attacker to implement multiple hardware-specialized system) valuable
> like done by some crypto-currency?
> The assumption is that if i need to buy 10 different specialized-ASIC to
> attack a specific crypto, it's obviously going to cost more.

Yes, until this specific combination becomes widespread enough that
there's sufficient incentive to produce ASICs for it.

But I don't recommend this to you.

Alexander


More information about the cryptography mailing list