I realize I'm replying here about 9 months after the last post... but I think I may have something to add. I was under the impression (since I last looked into the password cracking topic about 15 years ago), that back then the latest preferred method was to use "rainbow tables". As I recall, this is basically a huge file that contains confirmed hashes that correspond to specific passwords. With this table, the cracking software no longer needs to brute force each hash - the rainbow tables file is the output of huge brute force attempts. Thus, the cracking of passwords is now reduced to taking the hash of a password file, looking it up like a database search against the same hash already recorded in the rainbow tables file, and spitting out the clear text password in a split second, thus no brute forcing is involved at all - because that work was already done ONCE to create the rainbow-table file.

My point being, I don't think there's any point at all in creating an ASIC to brute force crack passwords, because rainbow tables already have all the brute force work reduced to one (or more) huge file(s). I believe there are online projects where hacke....er... people are creating multi-terabyte sized rainbow table files that contain every possible hash variation of X length passwords. If anything, a custom ASIC could be used to create these rainbow tables much faster than normal PCs or GPUs; but to provide real-time password cracking services, probably doesn't make that much sense (I think). So with rainbow tables, I think the speed of finding the password in a hash becomes more about I/O - how fast can the hash/password finder application dig through multi-terabyte files to match the hash you are looking for? In theory, if the rainbow tables are like indexed databases, even multi-terabyte files should yield a password recovery in a few seconds.

Comments?

Quote from: gat3way on July 05, 2012, 08:25:10 AM

Of course it is possible to design a dual-purpose (SHA256 cracking/mining) chip, it would very likely mean larger die size and more layers thus higher NRE costs and higher end-product costs.

End result being customers paying more to get the same hashrate. There isn't that much demand for SHA256 cracking actually, in fact sha256 is not widely used, thus it is highly unlikely you'd ever pay off your ASIC miner in case bitcoin collapses simply because demand is low. A better idea would be to create a dual-use chip that can perform custom number of PBKDF2 iterations, it can then be easily reused by software to crack different stuff (WPA-PSK, ZIP 3.x, protected OpenOffice docs, FileVault, encrypted IOS/blackberry backups, etc). Problem being PBKDF2-SHA1 is so radically different as compared to SHA256 that you'd be much better off selling two different boards together.

Overall though fast ASICs are not quite useful for hash cracking unless you are a three-letter agency that can afford producing lots of different designs. Also unlike bitcoin mining, it is not all about speed, cleverly exploiting low password entropy by reducing keyspace in some way, generally works better (otherwise cracking passwords of length >=10 would be extremely uncommon). Simple bruteforce attacks are dumb and generally it's much more practical to write some good wordlist mangling rules as compared to bruteforcing. Even statistical attacks like ones based on markov models are generally much better than bruteforcing. Yet markov attacks require good input models and rule mangling requires much more skill as compared to bitcoin mining.