Someone interested in keeping that kernel up with 2.6? 3-component vectors are working now and it would need to get reordered a bit again to get better ALUPacking as the compiler backend has apparently changed in a way. I lost my interest in bitcoin, but it would be an interesting experiment. I believe pre-2.6 speeds can easily be regained.

The OpenCL compiler does involve constant folding as an optimization pass. It is an obvious optimization, no need to try this.

100% CPU bug is partially fixed on Linux now. Much better than before, still worse than pre-2.5.

Still coding OpenCL stuff, Diapolo?

Brook+ is something deprecated in ATI Stream (now AMD APP) SDK a long time ago. You can consider it as some kind of an OpenCL predecessor. That's was the framework that I used when I got into GPGPU development. It looks like a very very limited C++, rather brain-damaging. Common things like arrays were not allowed in kernels. No local memory, no barriers, limited scatter-gather that was performed into reduction steps and stuff like that, it's like a nightmare from the past. Lucky for me I quickly switched to OpenCL which was something new back then and was also very badly supported. And no, Brook+ is not a heterogenous compute environment, it does not support CPUs. It also has nothing to do with OpenCL.

Actually I doubt recent AMD APP SDKs ship with even brcc. Headers are gone a long time ago. Well, even CAL/IL is being deprecated nowadays.

What GPU are you using and what command-line arguments?

Just want to point out some things.

First off it's incorrect that candidates of length <=64 bytes take the same time to hash. The "boundary" in question (after which you calculate another compression function for the padding) is 55. Remember you need to add a 1 bit which would overwrite the last 8 length bytes.

Also depending on implementation, calculating hash of a 4-byte candidate might be faster than calculating say 32-byte candidate hash. That's because there is a common optimization that can be done: if w

• is always zero, then you can skip some of the ALU operations regarding it. That's because X ^0 = X and X+0=X and X|0=X and so on.

Key stretching (e.g PBKDF or using phpass) is the common way to increase security. However that comes at a cost. Large forums with many users and lots of authentication attempts would consume a lot of CPU resources.

Not that good idea. This all lies on the assumption that the attacker would not be able to access the filesystem which is not necessarily the case. Depending on configuration, the user might be able to read arbitrary files using e.g mysql's LOAD_FILE(). The forum software might have other attack vectors like LFI that would allow reading the file. The salt file should be outside the document root but that would break some (already inefficient) security mechanisms like open_basedir. Short enough salts would fall victim to simple attacks (like registering an user with a single-character password then bruteforcing to obtain the salt). But what's worst - you'd have a single salt for all the passwords that way. This is enough to thwart rainbow table attacks if salt is long enough (even 10 bytes of salt is enough to render readily available tables useless). But there is also another huge advantage of using salts which you are losing by using a single common salt. You turn the complexity of a hash crack attack from (nearly) O(1) to O(N) where N is the number of passwords. That's because if all passwords have the same salt, you do:

1) hash = H(salt,password)
2) compare hash to all the hashes in the list.

overall that's one compute-intensive operation per candidate


if you have many salts, you need to do the following:

for each hash K in the list do:
  1) hash = H(salt, password)
  2) compare hash to K

overall that's N compute-intensive operations per candidate where N=number of users.


So yes, it might be a good idea if you can guarantee that the attacker would never get the salt. Once it gets it though, you lose a great deal of the time that password hashing buys you prior to your hacker obtains your password. For a forum of 1000 users, cracking the passwords using a single common salt would be up to 1000 times faster than cracking 1000 passwords with different salts.

So you think mentioning the SMF password hashing algorithm helped the attacker to crack the hashes? I don't think so. Actually just posting them on a site like hashkiller.com or insidepro.com would be enough to get a decent part of them cracked.

But hey I just gave out more sensitive data to the potential attacker. Damn

That's completely wrong.


No, it did not.


SMF is an opensource product and the way it hashes user password is well known.

Well, those are the bruteforce cracking speeds for the most popular forum engines' password hashes on AMD Radeon HD6870:

IPB/MyBB: ~500M/s
vBulletin: 700M/s (older versions with short salts) - 512M/s (newer versions with 30-byte salt).
SMF: 980M/s

Those are bruteforce speeds, single-hash, using my own software. oclHashcat has nearly the same speeds, +/- 1-2%. 

Note that since those are salted hashes, speeds are proportional to the number of hashes. E.g cracking two IPB hashes would run at 250M/s, cracking 1000 IPB hashes would run at 500K/s.

Bruteforcing thousands of salted hashes is not very practical. However, with dictionary and rule-based attacks, things are kinda different. And long passwords are not necessarily strong ones.

P.S I did not mention phpbb3 as I haven't implemented it yet, but I can make projections about speed (as it is iterated MD5 in fact) - it should be about 3M/s on 6870 which is significantly slower. PHPBB3's password hashing is much better as compared to IPB/vBulletin/SMF in fact.

Sorry, the bitcoin plugin is a very low priority for me right now, I am working on completely different part related to hash cracking.

As far as your problem is concerned: where did you get hashkill from? Did you build it from source?

The "official" 0.2.4 version does _not_ contain the bitcoin code. It is experimental and meant to be included in 0.2.5 if it gets stable enough. There are still issues with it and unfortunatelly it is a low priority right now. Most of my efforts right now are towards migration to precompiled kernels and the rule engine for password cracking.

What they do is overlapping kernel execution and host-device transfers. It is generally possible but troublesome with OpenCL and AMD APP SDK. It is done by using asynchronous kernel invocations and buffer reads (supplying CL_FALSE as the "blocking" function argument and callback functions also supplying CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE while creating the queue). This requires DMA support which works with 2.4 only. Keep in mind that it depends very much on the task being performed - the way all bitcoin kernels are written would not allow this.

It would be possible if there were no "reduction", e.g all workitems write their output in their part of the grid, e.g for NDRange of 1,000,000 nonces, you have an output buffer of 1,000,000 uints. This way you may overlap transfers and kernel executions.

It wouldn't be much faster (in fact I wouldn't be surprised if it turns out to be slower). Also, people that underclock memory will definitely suffer.

P.S those might be helpful:

http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=144609
http://forums.amd.com/devforum/messageview.cfm?FTVAR_FORUMVIEWTMP=Linear&catid=390&threadid=134450

From a miner perspective that was one of the things I targeted for hashkill, but unfortunately it would likely never be released because I have other things to do and bitcoin plugin development is currently frozen. I planned to have two multi-pool modes, failover and load-balance. Failover is easy, but it was exactly long polling that makes load-balance mode difficult to get done properly. My task was also even harder because I spawn a number of workthreads per GPU and utilize all the GPUs within one process. I experimented a bit and found out it is actually hard to get that done properly. Actually I still can't find the best strategy for doing that.

Alright,

1) Since I moved from global queueing mechanism to queue/thread, using -G4 (especially with multi-gpu systems) is rather troublesome. It will not bring you benefits in terms of performance as compared to -G2. It would likely allow you to hit the anti-DDoS protection on pools though. Even if it doesn't, this would likely guarantee you higher stale percentage.

2) Yes, -D is the right thing to do. It provides higher speeds but has theoretically lower efficiency (should be about 0.2% less efficient and speeds should be ~1-2% faster though which makes it "profitable").

Desktop lag using -D can be relatively insignificant with fastest GPUs and really brutal with slow ones.

As for options/naming (those that concern bitcoin plugin in particular):

-D (comes from "double mode" which is more correct with hash cracking, not bitcoin, but I reused the switch anyway): this increases the global work size thus reducing host-device transfers per getwork. The side-effect being that GPU is overhauled with calculations.

-p is the plugin thing, correct

-G option specifies threads/device ratio. Either provide -G2 (for NVidia with newer drivers) or leave it. In most occasions, default setting is best.

-a specifies API key to use for statistics (available with some pools only when you press ENTER while mining)

-f <filename> specifies a file containing a list of pools for the failover mechanism. People reported it to crash with deepbit.net though for a reason I have not investigated.

-T specifies temperature threshold (in Celsius). When some of your GPUs reach it, it would be disabled for a minute or more to avoid overheating and avoid the aggressive driver thermal throttling. Default is 90C.


hashkill cannot send statistics to sockets, but provides a mechanism to get them from external script. Statistics (speed, processed, submitted, stale and eff) are stored in json format once in 3 seconds in ~/.hashkill/bitcoin.json.

Yes.

Yes, there is a temperature threshold (default being 90 but it's configurable via command-line). When it's reached, the GPU sleeps for a minute. Downclocking it is risky.

Use SDK 2.4.

Gotta be JPMorgan Now all they need to do is withdraw their money....through mtgox, aheheheaha.