## Bitcoin Mining ASICs used for cryptographic application? Rainbow tables?

34

6

What is the potential that the ASICs being developed for mining could be used for other cryptographic applications such as building rainbow tables? I know that for instance those that crack GSM with rainbow tables utilize systems similar to those for mining for building rainbow tables and decrypting GSM packets. Such systems are also used for building MD5, SHA, rainbow tables for traditional password/shadowfile cracking.

25

The ASICs are optimized for bitcoin mining. Not just Sha256(Sha256(x)) hashing, but very specifically bitcoin mining. You can't even use them for the Sha256(Sha256(x)) hashing in the rest of the bitcoin system, like hashing transactions.

The ASICs are made for hashing 80 bytes, where you give them the midstate from hashing the first chunk (64 bytes), and 12 bytes from the second chunk. They then try all variations of the last 4 bytes to try and find a hash that starts with 4 zero-bytes. Only values that result in the 4 zero-bytes are reported at all. That's basically what mining is.

The ASIC could aid in password cracking if:

• the hashes are generated with sha256(sha256(x))
• salt + password = 80 bytes
• the hash starts with 4 zero-bytes

I don't even think it would help there since password cracking requires that you find a password with the exact hash whereas an ASIC seeks only a hash with a value less than or equal to another one. – jeteon – 2016-07-16T17:52:20.040

If the password hash starts with 4 zero-bytes like I wrote above, then it would find those candidates, which would be a great help. However you will likely never be in a situation where these prerequisites are present. – Dr.Haribo – 2016-07-16T17:54:58.537

No you wouldn't. A hash that starts with 5 zero bytes, for instance, would meet the goals of the ASIC and it would stop. It never seeks an exact hash value, only one that starts a certain way which is why you can't recover passwords with it. – jeteon – 2016-07-16T19:02:04.287

It doesn't stop but continues and reports more results. At least the ASICs at the time this answer was written. However since then there are now ASICs that don't scan the entire nonce-range, and ASICs work so quickly that they are not able to report all nonces that result in 4 zero bytes. These new ASICs are even more useless for password cracking. – Dr.Haribo – 2016-07-16T19:06:07.043

5

ASICs for BTC mining are optimized for one calculation: SHA256(SHA256(x)). They can not be used to calculate MD5(x) or even SHA256(x), so unless you use double-SHA256 to hash your passwords, you should not be worried.

Assuming one does use double-SHA256 i'd be interested to know the effect of using a Bitcoin ASIC miner to attack such passwords. What I am trying to gauge is the side-effects of such innovations for other purposes. – gesell – 2013-01-23T14:31:51.160

1If you use double-SHA256 for password hashes and someone is able to download your database, an ASIC miner chip would make bruteforce cracking these passwords a lot faster. The hashrate of the chip is the rate at which they can attempt to find the password for a hash. – Philip Frank – 2013-01-23T14:39:34.463

1The question though is how does this change current risk models for double-SHA256 based authentication designs? Should people avoid using it? Would double-SHA be more secure now than double-SHA256? – gesell – 2013-01-23T15:51:59.253

3

Right, using double-SHA256 as a hash function in security systems is a bad idea going forward. Applying a hash function twice usually does not make a lot of sense anyways, if you want a stronger hash just use SHA512. For more info on the SHA family of hash functions, see http://en.wikipedia.org/wiki/Secure_Hash_Algorithm

– Philip Frank – 2013-01-23T17:27:41.273

1You probably shouldn't be worried about double-sha256 passwords either since for the purpose of password cracking you're looking for a collision in a 2^256 key space. The current gen ASICs make that much faster, but an exhaustive search of that large a key space with a 60GH/s ASIC would still take 6.1e+58 years – David Perry – 2013-01-23T17:56:48.190

How would 6.1e+58 compare to a double-SHA1 hask cracking rig (non asic or fpga)? – gesell – 2013-01-24T01:15:07.583

2@bananer: The hashrate is the rate at which they can attempt to find the password assuming they can load candidate passwords to the chip at that rate, which would be nearly impossible with an ASIC meant for mining. They just don't have high-bandwidth paths into their mining cores because they have no need for them and that would take up lots of space. – David Schwartz – 2013-01-24T05:45:36.573

2

A potential use I can think of is for aiding mailing servers using a variant of HashCash to validate they're not spammers: should HashCash users start using SHA-2 instead of SHA-1 for the proof-of-work, then ASIC miners could be reused to aid mail severs send authenticated mails to large distribution lists, thus reducing the cost for honest corporate (or even personal, should the need arise!) massive mailing.

Of course, this also means spammers could simply get these machines to reduce the chance their mails get identified as the garbage they are - buying an ASIC would simply become another "investment" needed to start a spamming business. So here goes the egg and chicken problem...

1

Lets say you want to build a rainbow table of double-sha-256, you then want to calculate 2^256 hashes which is 1.579*10^77 hashes lets divived by on the average ASIC power we have (one at 30Ghash/s):

1.579*10^77 hash / 30,000,000,000 hash/s
3.8596*10^66 seconds
Or 1.2238*10^59 years

Which is, correct me, more than the time of the UNIVERSE!

And if we took the actual bitcoin network power (@ about 20 Thash/s), we would still wait 1.8358*10^56 YEARS. Which is not even really faster.

So well good luck trying to do a rainbow table, I guess.

1Highly Irregular raises a valid point... How difficult would it be to create a rainbow table for all passwords with just English alphanumeric chars (including whitespace) of, at most, 15 characters long? Using an ASIC to do the hashing, this starts to look feasible, probably doable in some months - after which such rainbow tables could be used to scan the addresses, looking for weakly created private keys... – Joe Pineda – 2013-05-30T23:43:37.880

You would not need a rainbow table at all if you've got a very fast ASIC. In the end the computing power would simply be high enough that it could fill a very large table pretty fast. Especially if a sufficiently large & random salt is used, you'd need a rainbow table per password, which kind of defeats the purpose of such an expansive & expensive solution. – Maarten Bodewes – 2016-04-11T16:41:14.527

I guess the goal is to try to dictionary attack the password (or brute force over a short range, say 8 characters), which limits the number of tries you need to do. – Gopoi – 2016-04-11T17:37:55.183

2Each of the 1.579e77 hashes would also need 32 bytes (256 bit) in your database. What is that, like a galaxy worth of microSDs? – Philip Frank – 2013-01-24T23:51:43.210

Yeah I didn't thought of that or what would be the space needed in 1 TB harddrive? – Gopoi – 2013-01-25T01:43:33.423

3It's still useful to build rainbow tables for passwords, even if you can't cover all cases, as most people use short passwords without special characters. I bet there are ASICs out there built to do it too... – Highly Irregular – 2013-01-25T18:51:09.653

0

TL;DR: Yes, bitcoin ASICs can serve cryptanalytic purposes.

They could be used to speed up a cryptanalytic attack that requires a lot of random bit-strings whose SHA256 begins with many zero bits. Bitcoin miners will report bitcoin header blocks M such that sha256(sha256(M)) begins with a prescribed number of zeros. In particular, this means that M'=sha256(M) is a random 256-bit blob whose hash begins with many zero bits.

One particular situation where this can be useful is the computation of a 3SUM on sha256. See this page for more details.