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

CC BY-SA 3.0
2013-01-23T14:31:51.160Z
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
CC BY-SA 3.0
2013-01-23T14:39:34.463Z
If 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
CC BY-SA 3.0
2013-01-23T15:51:59.253Z
The 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
CC BY-SA 3.0
2013-01-23T17:27:41.273Z
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
CC BY-SA 3.0
2013-01-23T17:56:48.190Z
You 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
CC BY-SA 3.0
2013-01-24T01:15:07.583Z
How would 6.1e+58 compare to a double-SHA1 hask cracking rig (non asic or fpga)?
gesell
CC BY-SA 3.0
2013-01-24T05:45:36.573Z
@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
CC BY-SA 3.0
2013-01-23T14:11:51.680Z
2013-01-23T14:11:51.680Z
Philip Frank
<p>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.</p>

<p>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...</p>

CC BY-SA 3.0
2013-05-30T23:55:22.170Z
2013-05-30T23:55:22.170Z
Joe Pineda
<p>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):</p>

<blockquote>
  <p>1.579*10^77 hash / 30,000,000,000 hash/s<br>
  3.8596*10^66 seconds<br>
  Or 1.2238*10^59 years </p>
</blockquote>

<p>Which is, correct me, more than the time of the UNIVERSE!</p>

<p>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. </p>

<p>So well good luck trying to do a rainbow table, I guess.</p>

CC BY-SA 3.0
2013-01-24T23:51:43.210Z
Each 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
CC BY-SA 3.0
2013-01-25T01:43:33.423Z
Yeah I didn't thought of that or what would be the space needed in 1 TB harddrive?
Gopoi
CC BY-SA 3.0
2013-01-25T18:51:09.653Z
It'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
CC BY-SA 3.0
2013-05-30T23:43:37.880Z
Highly 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
CC BY-SA 3.0
2016-04-11T16:41:14.527Z
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
CC BY-SA 3.0
2016-04-11T17:37:55.183Z
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
CC BY-SA 3.0
2013-01-24T04:08:04.870Z
2013-01-24T04:08:04.870Z
Gopoi
<p><strong>TL;DR: Yes, bitcoin ASICs can serve cryptanalytic purposes.</strong></p>

<p>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 <code>M</code> such that <code>sha256(sha256(M))</code> begins with a prescribed number of zeros. In particular, this means that <code>M'=sha256(M)</code> is a random 256-bit blob whose hash begins with many zero bits.</p>

<p>One particular situation where this can be useful is the computation of a 3SUM on sha256. See <a href="http://cristal.univ-lille.fr/3sum-pool" rel="nofollow noreferrer" title="this page">this page</a> for more details.</p>

CC BY-SA 3.0
2017-10-07T15:09:39.713Z
2017-10-07T15:09:39.713Z
Charles Bouillaguet
<p><strong>TLDR; forget about it.</strong></p>

<p>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.</p>

<p>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.</p>

<p>The ASIC could aid in password cracking if:</p>

<ul>
<li>the hashes are generated with sha256(sha256(x))</li>
<li>salt + password = 80 bytes</li>
<li>the hash starts with 4 zero-bytes</li>
</ul>

CC BY-SA 3.0
2016-07-16T17:52:20.040Z
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
CC BY-SA 3.0
2016-07-16T17:54:58.537Z
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
CC BY-SA 3.0
2016-07-16T19:02:04.287Z
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
CC BY-SA 3.0
2016-07-16T19:06:07.043Z
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
CC BY-SA 3.0
2013-01-24T22:36:05.913Z
2016-02-17T21:24:28.960Z
2016-02-17T21:24:28.960Z
Dr.Haribo
<p>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.</p>

<asic><cryptography><mining-hardware>
Bitcoin Mining ASICs used for cryptographic application? Rainbow tables?
gesell
# Bitcoin Mining ASICs used for cryptographic application? Rainbow tables?

(Asked by: username_0 on 2013-01-23)

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.

**Tags:** asic, cryptography, mining-hardware


---

## 5 answers

### Answer by username_9 on 2013-01-24. Score: 26 | Accepted answer

**TLDR; forget about it.**

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

> **Comments:**
> **username_10**: 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.  
> **username_9**: 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.  
> **username_10**: 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.  
> **username_9**: 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.  

---

### Answer by username_1 on 2013-01-23. Score: 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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: If 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.  
> **username_0**: The 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?  
> **username_1**: 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  
> **username_2**: You 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  
> **username_0**: How would 6.1e+58 compare to a double-SHA1 hask cracking rig (non asic or fpga)?  
> **username_3**: @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.  

---

### Answer by username_4 on 2013-05-30. Score: 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...


---

### Answer by username_5 on 2013-01-24. Score: 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.

> **Comments:**
> **username_1**: Each of the 1.579e77 hashes would also need 32 bytes (256 bit) in your database. What is that, like a galaxy worth of microSDs?  
> **username_5**: Yeah I didn't thought of that or what would be the space needed in 1 TB harddrive?  
> **username_6**: It'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...  
> **username_4**: username_6 username_6 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...  
> **username_7**: 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.  
> **username_5**: 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.  

---

### Answer by username_8 on 2017-10-07. Score: 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](http://cristal.univ-lille.fr/3sum-pool "this page") for more details.


---

