Dual use ASICs, Mining and Cracking

[Transisto]

Given ASICs have near zero resale value in the event of a bitcoin collapse.

Could someone technical explain; How different is Bitcoin mining to SHA cracking and how much more would it cost to fab such a dual use device ?

Albeit small, I see no end in demand for SHA-1 & 2 cracking, be it for legit password recovery services or evil hacking of encrypted assets.
If the cost is marginally higher (30%) it could significantly reduce the investment risk.

[1715321439]

1715321439

[1715321439]

1715321439

[1715321439]

1715321439

[1715321439]

1715321439

[rjk]

Certainly it would be possible with some trivial design changes to support both - but the only cracking application it would have is with SHA256, and nothing else at all.

Since a bitcoin hash is one SHA256 piped into another SHA256, you would just need to provide a way to get info into and out from the middle of that 2-step process.

[Transisto]

Wondering ,,, Since BFL isn't specifying anything about Bitcoin mining in their ASICs press release, is it safe to assume it can also do something else too ? like cracking ?

 

[BinaryMage]

I suspect it would be convertible, but they probably don't want to publicize that fact - more negative press is the last thing both Bitcoin and BFL need right now. I can just see the headlines:

"Shady Bitcoin Company Launches New Units, Hackers Reverse Engineer Them and Hack <Insert Major Website Here>'s Password Database"

"Password Theft - The Future of Bitcoin Mining?"

"Bitcoin - The Virtual Currency it Appears to Be OR The Largest Hacking Operation the World Has Ever Seen?"

[crazyates]

Correct me if I'm wrong, but this can't happen with their ASICs. Password cracking works backwards from hashing, right?


The general idea of mining is to run thru a SHA256 hash twice. They take x and turn it into y like this:

y = (SHA256 (SHA-256 (x)))


This is assuming their ASIC does both steps at once. Their ASIC may only do one hash at a time, but it would still look like this:

z = (SHA256 (x))
y = (SHA256 (z))

For password cracking, you would need some way to go from an already encrypted password that's only gone through one SHA256 encryption (z, in the example above), and un-encrypt it into x. It was my impression that this sort of password cracking works backwards from bitmining. The ASIC could be use to encrypt passwords, but there would be no use for something that fast.

Bitmining: x --> SHA256 --> z --> SHA256 --> y
Password: x --> SHA256 --> z
Cracking: z --> CRACK --> x


Does that make sense? Anyone more knowledgeable care to point out any blatantly obvious holes in my reasoning?

[DeathAndTaxes]

Bandwidth would be a problem.

Bitcoin miners use very little bandwidth because they hash the same header 4 billion times (one with a different nonce).

If BFL Single (800 MH/s) was performing password cracking 1.6 billions passwords per second to supply raw blocks (which would be the most compatible w/ Bitcoin algorithm) would require 1.6 * 1000^3 * 512 bytes * 8 bits / byte = 6.4 terrabits per second.  (or ~ 50x bandwidth of 16 lane PCIe 3.0 adapter).  Now that is a BFL Single (65nm FPGA).  If an ASIC can acheive up to 200x higher performance you are looking at bandwidth requirements of ~ 1 pbs (petabit per second).

Bitcoin only uses a small amount of bandwidth because it works like this

block header sent to miner
hash block header w/ nonce 0
hash block header w/ nonce 1
....
hash block header w/ nonce 4294967295
new block header sent to miner

That doesn't apply to password cracking.  You likely "could" design a chip which did both but the compromises would mean it would be a less than optimal bitcoin miner.   The need for single pass mining, lower throughput, and higher bandwidth design would mean it hash higher cost, higher energy consumption and produces less hashes.  I doubt anyone will do that.  SHA-256 cracking is pretty niche so the "dual use" likely isn't worth more than the loss of performance costs.

[MrTeal]

Correct me if I'm wrong, but this can't happen with their ASICs. Password cracking works backwards from hashing, right?


The general idea of mining is to run thru a SHA256 hash twice. They take x and turn it into y like this:

y = (SHA256 (SHA-256 (x)))


This is assuming their ASIC does both steps at once. Their ASIC may only do one hash at a time, but it would still look like this:

z = (SHA256 (x))
y = (SHA256 (z))

For password cracking, you would need some way to go from an already encrypted password that's only gone through one SHA256 encryption (z, in the example above), and un-encrypt it into x. It was my impression that this sort of password cracking works backwards from bitmining. The ASIC could be use to encrypt passwords, but there would be no use for something that fast.

Bitmining: x --> SHA256 --> z --> SHA256 --> y
Password: x --> SHA256 --> z
Cracking: z --> CRACK --> x


Does that make sense? Anyone more knowledgeable care to point out any blatantly obvious holes in my reasoning?

Someone more knowledgeable than I am will probably chime in here, but they don't crack passwords like this. For cracking, you have the hash of the password. You then take your password guess, hash it, then compare that hash to the value you have. Rinse and repeat several trillion times.

[crazyates]

Correct me if I'm wrong, but this can't happen with their ASICs. Password cracking works backwards from hashing, right?


The general idea of mining is to run thru a SHA256 hash twice. They take x and turn it into y like this:

y = (SHA256 (SHA-256 (x)))


This is assuming their ASIC does both steps at once. Their ASIC may only do one hash at a time, but it would still look like this:

z = (SHA256 (x))
y = (SHA256 (z))

For password cracking, you would need some way to go from an already encrypted password that's only gone through one SHA256 encryption (z, in the example above), and un-encrypt it into x. It was my impression that this sort of password cracking works backwards from bitmining. The ASIC could be use to encrypt passwords, but there would be no use for something that fast.

Bitmining: x --> SHA256 --> z --> SHA256 --> y
Password: x --> SHA256 --> z
Cracking: z --> CRACK --> x


Does that make sense? Anyone more knowledgeable care to point out any blatantly obvious holes in my reasoning?

Someone more knowledgeable than I am will probably chime in here, but they don't crack passwords like this. For cracking, you have the hash of the password. You then take your password guess, hash it, then compare that hash to the value you have. Rinse and repeat several trillion times.

Bold added for emphasis

I'm not too up on my cryptology and password hacking, so I would not be surprised if you are right!

[BinaryMage]

Someone more knowledgeable than I am will probably chime in here, but they don't crack passwords like this. For cracking, you have the hash of the password. You then take your password guess, hash it, then compare that hash to the value you have. Rinse and repeat several trillion times.

Bold added for emphasis

I'm not too up on my cryptology and password hacking, so I would not be surprised if you are right!

This is correct, in the case we're referring to. (Certain methods more efficient than guessing and checking are usable with some hashing algorithms, but not SHA256 to my knowledge)

Since raw passwords are never (should never be) stored on the server, when a user signs up, their password is hashed at least once and hopefully salted (though not as frequently as they should be) before being put in a database. Through various methods irrelevant to this discussion, a hacker can gain access to that database and consequentially the hashed passwords.

Hopefully the server uses a good hashing algorithm such as bcrypt (multi-layered salted SHA256/512 isn't as good, but is usually sufficient). In this case, the hacker can't do much of anything with the database, as it is inefficient to brute force and impossible to reverse-hash.

However, in a startling number of cases (the MtGox hack for example), passwords are not well-hashed and salted, and are stored in a hashing algorithm such as SHA256, SHA1, or (heaven forbid) MD5 that is efficient. (read: hashes can be calculated quickly)

The hacker then proceeds to find a hash he/she wishes to crack and then attempts to brute force it by hashing standard alphanumeric strings until he finds the one giving the hash he has obtained. He can then use that string (which should be the user's password, except in rare cases) in order to log in to the website and wreak havoc.

Now, for some math. In the 95 character ASCII printable keyspace (usually around the number of different characters allowed in a password), checking every possible password up to 8 characters would take around 6.6 e+15 tries. While that seems like a lot, a 1 TH/s (1 e+12 hashes/sec) unit could process all of those in under two hours. (this is hypothetical, I'm not accounting for bandwidth limitations and the like)

Sorry, that was a bit long winded. Hopefully it's at least moderately understandable.

[cmg5461]

Now, for some math. In the 95 character ASCII printable keyspace (usually around the number of different characters allowed in a password), checking every possible password up to 8 characters would take around 6.6 e+15 tries. While that seems like a lot, a 1 TH/s (1 e+12 hashes/sec) unit could process all of those in under two hours. (this is hypothetical, I'm not accounting for bandwidth limitations and the like)

Sorry, that was a bit long winded. Hopefully it's at least moderately understandable.

Now the scary thing, watch the curve as you go to 9, 10 and 11+ characters.

passwords should be 9+ characters, as that would take years for the average person to crack it with average equipment.

edit-



this is what I was referring to

[MrTeal]

Now, for some math. In the 95 character ASCII printable keyspace (usually around the number of different characters allowed in a password), checking every possible password up to 8 characters would take around 6.6 e+15 tries. While that seems like a lot, a 1 TH/s (1 e+12 hashes/sec) unit could process all of those in under two hours. (this is hypothetical, I'm not accounting for bandwidth limitations and the like)

Sorry, that was a bit long winded. Hopefully it's at least moderately understandable.

Now the scary thing, watch the curve as you go to 9, 10 and 11+ characters.

passwords should be 9+ characters, as that would take years for the average person to crack it with average equipment.

edit-



this is what I was referring to

No offense, but that's a completely useless (and actually deceptive) graph.  The scale on the y axis is really poorly chosen.

[cmg5461]

Now, for some math. In the 95 character ASCII printable keyspace (usually around the number of different characters allowed in a password), checking every possible password up to 8 characters would take around 6.6 e+15 tries. While that seems like a lot, a 1 TH/s (1 e+12 hashes/sec) unit could process all of those in under two hours. (this is hypothetical, I'm not accounting for bandwidth limitations and the like)

Sorry, that was a bit long winded. Hopefully it's at least moderately understandable.

Now the scary thing, watch the curve as you go to 9, 10 and 11+ characters.

passwords should be 9+ characters, as that would take years for the average person to crack it with average equipment.

edit-



this is what I was referring to

No offense, but that's a completely useless (and actually deceptive) graph.  The scale on the y axis is really poorly chosen.

The difference between each line is 2.5E19...

1,000,000,000,000,000,000,000
750,000,000,000,000,000,000
500,000,000,000,000,000,000
250,000,000,000,000,000,000
0

That look better?

The graph is 100^x, in case you're wondering

[pieppiep]

You should not use a linear scale but a logarithmic scale

[cmg5461]

You should not use a linear scale but a logarithmic scale

1. It's not my graph

2. Who uses logarithms for portraying time.  # hashes directly correlates with time.  # hashes is the independent variable.

[MrTeal]

No offense, but that's a completely useless (and actually deceptive) graph.  The scale on the y axis is really poorly chosen.

The difference between each line is 2.5E19...

1,000,000,000,000,000,000,000
750,000,000,000,000,000,000
500,000,000,000,000,000,000
250,000,000,000,000,000,000
0

That look better?

The graph is 100^x, in case you're wondering

That's not the issue. For something like that you should use a log scale. I could take the exact same function and make these graphs.

Why use 9+, look at how it shoots up at 8!

[cmg5461]

doesn't portray much of a point, does it?



Too bad you only live < 110 years

[MrTeal]

doesn't portray much of a point, does it?

Actually, I think it shows the point very clearly. Difficulty is an exponential function of password length. It's the other graphs that aren't clear.

[cmg5461]

Actually, I think it shows the point very clearly. Difficulty is an exponential function of password length. It's the other graphs that aren't clear.

Congrats, you've passed algebra.  To some it looks like a straight line.  To some it is a straight line.  Keeping things is prospect to something you can relate to, shows the magnitude of the situation.  ie time.

[BinaryMage]

There's a more fundamental problem than choice of scale in those graphs - using current hardware speeds to predict times to crack of years or more is meaningless; hardware speed increases exponentially.

More characters in a password will certainly help, but you'd be surprised how high a percentage of users use 8 character or less passwords. Remember, we're not discussing how to secure your account - we're discussing the potential power and implications of the use of ASICs for SHA256 cracking.

[cmg5461]

There's a more fundamental problem than choice of scale in those graphs - using current hardware speeds to predict times to crack of years or more is meaningless; hardware speed increases exponentially.

More characters in a password will certainly help, but you'd be surprised how high a percentage of users use 8 character or less passwords. Remember, we're not discussing how to secure your account - we're discussing the potential power and implications of the use of ASICs for SHA256 cracking.

I figured in 100 million hashes per second. following moores law, we can make the hashing power double every two years to see what kind of impact that makes on it.  I'll do it when I get to work.

Edit: takes a ton of loops.  Too lazy to do it in excel.