Cryptohaze.com

Bitweasil wrote:

crazydoc wrote:It would be very interesting to distribute cracking on two or more machines, each with a supported graphics card. For example, I like the way the (Windows-) tool "LCP" does it. There you can split the work in as many parts as you want and the tool will create files containing the info what to do on a certain machine.

Interesting idea.

Not likely to be implemented terribly soon, though I am working on multi-GPU support (as multi-core GPUs seem to be the way everyone is going right now).

My goal for distributed work is the rainbow tables right now. The brute forcers are an interesting side project.

With the possibility of distribution, woudn´t it be possible to use it on multi-GPU-systems without doing major chances of the code? Your tool already have a switch for selecting the GPU to use. So you could your tool start twice, first instance working on the first half of the keyspace on GPU0 and the second on the other half on GPU1. AND you can distribute cracking on multiple machines, not only GPUs.

Simple textfiles could provide the info necessary, for example:

(For Machine1 / GPU1)

Code: Select all

Hash algorithm: NTLM
Charset: abcdefghijklmnopqrstuvwxyz
MinLen: 3
MaxLen: 3
Starting point: aaa
End point: maa

(for Machine2 / GPU2)

Code: Select all

Hash algorithm: NTLM
Charset: abcdefghijklmnopqrstuvwxyz
MinLen: 3
MaxLen: 3
Starting point: mab
End point: zzz

Would this solution have any drawbacks compared to a Multi-GPU-usage?

Hm. That's an interesting idea, though it continues to add complexity to an already-difficult-to-tune tool.

It also will require threading to do properly (at least to do it within a single binary), which is fun to make cross-platform.

The "parts file" does seem to be a good option.

I'll look into it. That would add resume capabilities as well, if I wrote it out as a checkpoint file.

Are people opposed to needing to manually break up large spaces into separate resume files to do multi-GPU or multi-system support right now?

And, basically, any objections to a really rather complex setup process if the performance results are insane?

Bitweasil wrote:That said, I do have some ideas up my sleeve that may *dramatically* improve performance on high hash counts. Order of magnitude or more, potentially. InsidePro is doing a much better (faster) job on large hash lists, and I had some brainstorms on how they might be doing it.

Preview of benefits (without it fully implemented:

On a list of 4000 hashes (max supported by the old version), on an 8600GT:

Code: Select all

Work: 229 Done: 0.38% Time: 494.51 ms Stp/srch: 1.2M/s 4741.9M/s


On my new version, same hash list:

Code: Select all

Work: 8052 Done: 12.63% Time: 497.45 ms Stp/srch: 41.4M/s 165748.6M/s


New version, list of 550000 hashes:

Code: Select all

Work: 600 Done: 6.37% Time: 99.51 ms Stp/srch: 15.4M/s 8489514.0M/s


I'm not done yet...

Closer to done (not likely to see significant improvements over this until I get the hash reversing working, which is a lower priority than a bunch of other stuff, though someone else is free to do so once I get the code a bit cleaner):

On a GTX260/216SP

1M hashes:

Code: Select all

Work: 112 Done: 0.10% Time: 494.53 ms Stp/srch: 59.4M/s 59369280.0M/s


5M hashes:

Code: Select all

Work: 222 Done: 0.07% Time: 481.00 ms Stp/srch: 60.5M/s 302471968.0M/s


Note the lack of drop in stepping rate between 1M & 5M.

And for something more practical:

50k hashes:

Code: Select all

Work: 422 Done: 0.29% Time: 489.92 ms Stp/srch: 225.8M/s 11678119.0M/s


InsidePro is still faster, and I know I could optimize it more, but I'm happy with this for now. And this one is free. Plus Mac/Linux compatible, and something resembling open source (once I clean up the code - right now it's very, very ugly, and I'm trying to clean up the framework & add utility functions/documentation such that it's easy to add new hash functions if you're a C coder). Salted support is still in progress as well, but the tricky bits I wanted to implement for multi-hash cracking are done for now - just need to port them to the rest of the hash lengths and verify.

Plus, these are really just to play around with. My real focus is going to be on the rainbow tables & wordlist based GPU cracking tools.

nice nice keep up to great work.

Hm... how about per-position charset support?

Still working out how I'm going to do it and if it's going to be a separate "hash type" or not, but... I've got some stuff up my sleeve.

Trying to figure out how to do resume support too.

Definite speed-ups on large numbers of hashes, though.

Bitweasil wrote:Hm... how about per-position charset support?

that would be awesome! also it would be an unique feature afaik.

Well, so far, it's slower on small numbers of hashes than the old version, and degrades a lot more significantly when using very short kernel times (<50ms). Blarg. Such is the price of more setup per kernel execution.

However, by 100 hashes, performance is double the old version, and for larger numbers, it's even better. Plus it's not limited except by video RAM.

Additionally, I'm planning to have the per-position character set support ready to rock, which will allow increased flexibility on hashes where something is known, or even when it's suspected to end with a number.

Depending on final performance numbers, I may include a separate MD5 module for shorter hash counts, based on the old code (so faster on small numbers of hashes).

Hm... except for the fact that there's a fundamental flaw with *math* not allowing my current "work splitting" system to work with multiple length character sets... Hrm. *ponders more*

And, working.

I now support single charset & multiple charsets (one per position).

It's a bit slower (400M per sec vs about 430M per sec), so I may write a "FASTMD5" or such that only works with a single character set. I'll see. Lots to tweak before then, though...