02-19-2011, 03:52 AM
Hello Atom,
I understand how the increment is functioning with the explanation provided at the above link. As a seperate question I received a meesage saying "too many possible combinations" when I was attempting to process the following.
/.oclhascatbin.64 -m 2 -o output.txt hash.txt --salt-file=salt.txt --increment -1 ?l?u?d?s ?1?1?1?1 ?1?1?1?1?1?1?1?1?1?1?1? (Attack on salted md5's) 1 salt - 5 hashes.
The program obviously has built a default check and is advising not to run the hash based on # of years it would take. However as GPU processing is increaed and ATI hopefully fixes the issue with trying to install more the four individual 5970's in a single machine(8 cores); one may attempt to try to attack a keyspace of that length if we can get x8 5970's recognized under Linux.
Lastly when I processed the attack on the system removing the -n 320 --gpuloops=1024 parameters I was able to acheive rough 4.5B c/s. When I was running the attack with the no -n/gpuloops option the speed was around 1.3B c/s. The last modification was to reduce the -n 320 to -n 80 and I was around 5.5B c/s. So what I am asking is that is there a way to some how integrate by default the performance increase offered by the -n/gpuloops command in the next release so that the inclusion/removal of those two parameters is transparent to the user? I know you are working on a new release.
I understand how the increment is functioning with the explanation provided at the above link. As a seperate question I received a meesage saying "too many possible combinations" when I was attempting to process the following.
/.oclhascatbin.64 -m 2 -o output.txt hash.txt --salt-file=salt.txt --increment -1 ?l?u?d?s ?1?1?1?1 ?1?1?1?1?1?1?1?1?1?1?1? (Attack on salted md5's) 1 salt - 5 hashes.
The program obviously has built a default check and is advising not to run the hash based on # of years it would take. However as GPU processing is increaed and ATI hopefully fixes the issue with trying to install more the four individual 5970's in a single machine(8 cores); one may attempt to try to attack a keyspace of that length if we can get x8 5970's recognized under Linux.
Lastly when I processed the attack on the system removing the -n 320 --gpuloops=1024 parameters I was able to acheive rough 4.5B c/s. When I was running the attack with the no -n/gpuloops option the speed was around 1.3B c/s. The last modification was to reduce the -n 320 to -n 80 and I was around 5.5B c/s. So what I am asking is that is there a way to some how integrate by default the performance increase offered by the -n/gpuloops command in the next release so that the inclusion/removal of those two parameters is transparent to the user? I know you are working on a new release.