Topic: Does one "hash/sec" represent SHA256(SHA250(blah)) or SHA256(blah)? (Read 3160 times)

Conceivably you can treat password cracking as a lottery too. But it would be a lottery with a single winning ticket. There is one important property of password cracking: it has to be exhaustive, i.e. search all the elements of the possible password space.

On the other hand Bitcoin is a lottery where the winning tickets are plentifull and constantly changing. With a still Bitcoin network there is a new winning ticket every second: the block time increments. With a live Bitcoin network there are additional winning tickets that are added every time a transaction gets propagated on the network. The set of possible winning tickets is not going to infinity because the some ticket will cease to be winning once their acceptable time window expires. And obviously the set of winning tickets has to be reinitialized once somebody mines a block and you have to change the "previous block" field and rebuild the merkle tree of the unmined transactions.

Lets consider a reverse example: suppose that you have a super-fast password cracker that only checks even passwords, i.e. those ending with B,D,F,... The trivial way to defeat it would be to use a password that is odd, i.e. one ending with A,C,E,...

But the above defective password cracker will be a perfectly good Bitcoin miner. That is because when mining Bitcoin you don't need to be exhaustive, you can randomly drop tickets without checking them if they were winning. All the mining infrastructure and protocols is designed around this property: keep printing tickets as fast as possible and don't care if some of them are mangled or dropped.

It is a major conceptual difference and I hope I managed to convey it to you.

I'm not sure that's right; cracking passwords is quite like a lottery too. Jack the Ripper doesn't just crunch through all possible permutations for instance - it is trying to hit the needle in the haystack.

What hashing does for passwords is increase the time taken to try one permutation. In an example I calculated (I wrote a blog post on it last year) the ~10,000 rounds of hashing we use on some of our passwords increase the time to try each permutation from ~1/1,000,000th of a second to ~1/250th of a second for a typical 2 GHz Xeon core

In my example those thousands of rounds of hashing increasing the time taken by a hypothetical 1,000 quad-core machines to brute force a typical 8 character password (assuming you have the password file of course) from ~9 hours to ~4 years.

Hardware which can crunch SHA hashes at a rate many orders of magnitude more than a normal CPU effectively removes the advantage conveyed by the many rounds of hashing.

Kate.

Please give one example of a password system that allows only passwords that are exactly 80 bytes long. Thanks.

Edit: Or alternatively: give one example of Bitcoin mining device that doesn't hardcode 640 as the inner hash bitstream length.

You cannot actually "break" a SHA encrypted password, you can only find "collisions" with the hash.
if the hashes match then there is a very good chance your 'key' and the hashed result are the same, but there is not actually any way to find out if it is the actual password OR just a collision.
As regards ASIC's , these have been specifically manufactured to target the SHA256(sha256(x)) algorithm.
Whilst it CONTAINS SHA256, there are usually a number of internal optimizations, that make getting the majority of the work impracticable.

That is to say the ASIC usually only reports  a small fractions of the hashes that match a probable solution. The rest are thrown away!!!

So when you see 1GH/s, yes the chip internally produces 1GH/s 'possible' solutions, but in the end it will only externally report from 0-n solutions that match the 'difficulty' it is searching for.

The previous poster is not entirely correct in his assumption of  "The primary reason is that no know humanly usable password systems allows for passwords that have the exact binary structure of the Bitcoin block header."

The reality is that the miner chips DO NOT validate the internal structure of the header, in reality they do not give a S**t about what you feed them., they take a source string perform a function on it,  then look for a result that meets a particular criteria.

Whilst it is highly improbable a user would  have a double SHA256 hashed password matching a given difficulty.. who knows what goes on in the real world!!!

That said, with an FPGA  it is possible to make a couple of small modifications to the algorithm and as long as you have the bandwidth to grab the results of each SHA, then in theory you could use the device for password collision detection.

Short answer: Neither.

Long answer: Bitcoin hash is approximately SHA256^1.5(blah).

The inner SHA-256 is computed over 2 512-bit blocks that come from the 80-byte block header.

The outer SHA-256 is computed over 1 512-bit block that comes from the 32-byte inner hash.

Because the nonce field is in the second 512-bit block of the inner hash everyone makes an optimization and keeps the first 512-bit of the inner hash a precomputed constant, thus the inner hash is really only about half of the full SHA-256.

In addition to the above: password breaking is a systematic, exhaustive search of the space of possible passwords. Bitcoin mining is playing a lottery, no need to be either systematic or exhaustive.

So your Bitcoin miner can break exactly zero SHA-256 passwords. The primary reason is that no know humanly usable password systems allows for passwords that have the exact binary structure of the Bitcoin block header.

Sorry if this is a bit of a n00b question, but when people cite Ghashes/second or whatever for mining rates, does that refer to the number of SHA256 operations per second or the number of double-SHA256 operations per sec?

I'm asking since it has occurred to me (as it probably has to many of you!) that we are making some hardware that would be extremely good at breaking password files hashed with SHA256 (the industry gold standard hashing algorithm). At work we typically rely on many rounds of hashing (in the thousands) as our main defense against a putative attacker who has managed to obtain a password file somehow (eg. stealing a laptop). We don't use SHA256 but I want to work out how quickly an ASIC mining rig could potentially break such passwords.

Kate.