OSDev.org

single-threaded test outcome:

cocaine:

$ time ./cocaine.exe e80b5017098950fc58aad83c8c14978e 6
Collision Found!: e80b5017098950fc58aad83c8c14978e is : abcdef
Cracking took: 18.17s
Average h/s: 3372710.21 h/s

real 0m18.358s
user 0m18.217s
sys 0m0.061s

$ time ./brute e80b5017098950fc58aad83c8c14978e 6
Collision Found!
hash[e80b5017098950fc58aad83c8c14978e] = 'abcdef'
- time: 18.59s
- avg. hash/s: 3296342.02 h/s

real 0m18.640s
user 0m0.031s
sys 0m0.015s

$ time ./md5 e80b5017098950fc58aad83c8c14978e 6 6 1
initializing..
h/s:3862242.086957
(1) I found a collision!
message:abcdef
g_thread_active_cnt:0

real 0m23.590s
user 0m23.108s
sys 0m0.015s

multi-threaded test outcome:

$ time ./md5 e80b5017098950fc58aad83c8c14978e 6 6 2
initializing..
digest_target is 17500be8fc5089093cd8aa588e97148c
g_thread_active_cnt:1
h/s:1610514.000000
(2) I found a collision!
message:abcdef
g_thread_active_cnt:0

real 0m12.375s
user 0m24.280s
sys 0m0.030s

seems like i have to snif at cocaine again

finished sniffing and found some other problems in my code and updated it and voila roughly 25% faster. O what a decent night of sleep can do. I became a father for the 2nd time on the 29th of may, which is my birthday also, and finally i can sleep for 5 consecutive hours again. Me is happy.

$ time ./brute e80b5017098950fc58aad83c8c14978e 6
Collision Found!
hash[e80b5017098950fc58aad83c8c14978e] = 'abcdef'
- time: 14.73s
- avg. hash/s: 4161385.80 h/s

real 0m14.860s
user 0m0.031s
sys 0m0.000s

What kind of problems did you fix to get 25%!

removed yet another memcpy as it was not needed anymore due to the loop unroll and intergrated two loops into one. further more the test i moved to md5hash as you did. It seemed to help a few percent.

basically it works like this now pseudo code ofcourse:
the code was in the previous post. currently i'm building a multithread solution to see if i can improve further by is seems to be stuck near 5.2 Million hashes per second. needs more investigation.

btw are we as fast as cain already?

I've just added your corrections to my build and I'm getting ~2.43M h/s and on my box cain runs at ~3.31M h/s so sadly we haven even beat cain yet

the two fastest i can think of: cain, mdcrack, are both closed source, so theres little way to know how they did it

I've just added your corrections to my build and I'm getting ~2.43M h/s and on my box cain runs at ~3.31M h/s

only need another 36% speed increase. should be doable ahum.
back to the drawing board.

i don't totally understand the md5 sum process but could it be possible to sum just the first byte of the digest, and test it, etc...

Cain updates a pretty GUI and still is faster than ours!

looked into that but the answer is no. look at the hash function you'll see that A, B, C, D is used in every line. As for the GUI that hardly cost many time if handled correctly. i'll not be able to work on it today/tonight so'll look into it again tomorrow. Though we have come along way since 300 K hashes/sec.

I've just added your corrections to my build and I'm getting ~2.43M h/s and on my box cain runs at ~3.31M h/s so sadly we haven even beat cain yet

I did: (downloaded the code in the last post)
g++ brute.cc -lm -lpthread -O3 -march=i686 -o brute && time ./brute 5b9104dc42e2f8fdd3f6a801f7656d65 5
2.972 million hashes per second

I know you are telling the truth about being in the 4 million range simply because my very own gets 4.3 million, but if someone else runs it the total drops to some pitiful amount..

The question I am wondering is exactly how do we end up perfecting the algorithm just for our processors? Ok. You might say we kept changing and running until we got it right.. but I did not. I changed what I wanted to change and it worked and got a increase in hashes per second.

Let me get my other computer booted (AMD), and see if I get drastically different results.

ok, can you also post your'e code? The 4 M per second i got on a Intel Cure 2 Duo 2.23 GHz using only one core. Your 4 M is single or multi threaded?

hmm.. i also think mine works best on my box, per GHz, , also I've found that the MMX regs are 64bit and every CPU supports it, could we use those somehow?

p.s. new code for testing attached!

I ran mine single, one thread. (4.317414 million)

g++ cocaine.c -lm -lpthread -O3 -march=i686 -o cocaine && time ./cocaine 5b9104dc42e2f8fdd3f6a801f7656d65 5
2.918634 million hashes per second

My Laptop (Only computer doing any testing ever.)
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.40GHz
stepping : 8
cpu MHz : 1400.000
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up
bogomips : 2795.45
clflush size : 64

also I've found that the MMX regs are 64bit and every CPU supports it, could we use those somehow?

Yes. The MMX extension allows you to perform operations on two thirty-two bit values. It is not hard to do this by using the intrinsic functions provided by C/C++. I have used MMX this way before.

are you sure your h/s timer is working correctly? post the time results for a hash and see which finishes first

Is that faster?

No it isn't.

Removing what I thought might be good and adding -march=i686 (on a p4) ups this to 5.5 million. Adding -fomit-frame-pointer ups that to 5.7 million. This is still on a single core.

What if you generate the strings beforehand or separately?

wow!, oooo try mine!

p.s. i think os64dev's is now the fastest