How about a 1.1 RC2 for Linux? ;-) (LM, MD5(MD5()), etc)

[Bitweasil]

//EDIT: Removed the old RC1, added RC2. It's more stable and should segfault less with network stuff.
Also includes "--daemon" which will run the client in a very quiet mode, well suited for remote systems.
And it doesn't have the silly libboost/libargtable dependencies that RC1 did - I built it in my normal environment.

http://cryptohaze.com/RCs/CryptohazeMul ... 04.tar.bz2

Adds some algorithms.

DOUBLEMD5 - md5(md5($pass)) - lower ascii output off md5
MD5OFSHA1 - md5(sha1($pass)) - lower ascii output off sha1
SHA1OFMD5 - sha1(md5($pass)) - lower ascii outout off md5
TRIPLEMD5 - md5(md5(md5($pass))) - lower ascii output off md5
DUPMD5 - md5($pass.$pass) - request by someone, doubles the password before hashing it. So len3 will test "123123"
DUPNTLM - ntlm($pass.$pass) - same deal, NTLM
LM - LM($pass) - use charsets/charsetMicrosoft with this one, testing lowercase characters for LM is silly.

The output file feature for LM may not be working yet - I can't remember if I actually coded that up or just commented it out. It does output to stdout at the end of cracking, but the -o option may not fill the file yet...

Networking changes/tweaks:
- I've fixed the bug that caused Windows clients to crash the server on disconnect.
- I've made the client mode sit and wait for the server instead of exiting immediately. The client may segfault if the server exits, I plan to fix this soon.
- The server now has a --serveronly flag that will ONLY be a network server - I had issues with some algorithms or bugs crashing the server causing loss of work.

The server workunit class will still lose work if a client disconnects. I intend to fix this for 1.1. I may also add saving status to a file (and restoring from a file!)

Questions? Comments? Bugs?

[grutz]

Looks good. A couple of things with LM:

• libboost is forced to 1.40.0 - Ubuntu 10.04 LTS has 1.44.0.
• Maybe related to libboost, loading 100k LM hashes crashes with the error: Cuda error in file 'CHHashTypePlain.cpp' in line 889 : unspecified launch failure.
• Loading ~1000 LM hashes works fine.

With 500 LM hashes in a Linux 10.04LTS system w/ 3 GTX580 cards I achieve ~945M/s

By comparison here's JTR's test with AMD Phenom(tm) II X6 1100T Processors:

grutz@crackah:/opt/cryptohaze$ ../jtr/john/run/john --format=lm --test
Benchmarking: LM DES [128/128 BS SSE2-16]... DONE
Raw: 14580K c/s real, 14727K c/s virtual

grutz@crackah:/opt/cryptohaze$ mpirun -np 6 ../jtr/john/run/john --format=lm --test
Benchmarking: LM DES [128/128 BS SSE2-16]... (6xMPI) DONE
Raw: 75366K c/s real, 75366K c/s virtual

kgrutzma@avenger:/opt/cryptohaze$ ../jtr/john/run/john --pot=test.pot --format=lm --nolog --incremental pwdump-500.txt
Loaded 641 password hashes with no different salts (LM DES [128/128 BS SSE2-16])
Remaining 435 password hashes with no different salts
guesses: 0 time: 0:00:01:46 0.02% c/s: 6372M trying: SP0SIM9 - SP0SUMN

[grutz]

Minor bug... -o and -n output files are not being written to when using LM. They are when using NTLM.

[Bitweasil]

libboost is forced to 1.40.0 - Ubuntu 10.04 LTS has 1.44.0.

Yeah... my bad. Boost is supposed to be statically linked, but the box I built the beta on wasn't my normal box, and so is doing dynamic linking. The final build will fix this. Boost is being used for networking only on Posix environments, and threading on Windows.

Maybe related to libboost, loading 100k LM hashes crashes with the error: Cuda error in file 'CHHashTypePlain.cpp' in line 889 : unspecified launch failure.

I've not been able to reproduce this. I loaded roughly 500k LM hashes and had no problems. That error is happening in memory allocation/copying, so is it possible that something else was using a ton of memory on your GPU? Try restarting & see if it repeats - I'd definitely like to fix it if it's repeatable.

Related, I did just discover that my "merge hashes together" code is actually quite bad with large hash lists... *fixing before release*

With 500 LM hashes in a Linux 10.04LTS system w/ 3 GTX580 cards I achieve ~945M/s

Sounds about right. I just hit 1B with a 580 & 3x470s.

guesses: 0 time: 0:00:01:46 0.02% c/s: 6372M trying: SP0SIM9 - SP0SUMN

... How on earth is John faster by 6x on a CPU??? *confused*

[Bitweasil]

Minor bug... -o and -n output files are not being written to when using LM. They are when using NTLM.

Known & theoretically fixed, I will verify before release. I know '-o' is working, will verify -n.

[grutz]

guesses: 0 time: 0:00:01:46 0.02% c/s: 6372M trying: SP0SIM9 - SP0SUMN

... How on earth is John faster by 6x on a CPU??? *confused*

I don't think it is, this could be some incorrect display on John's side.

I regenerated 20k LM hashes and it loaded fine. I'll see if I can replicate some of the issue and save the LM hash list. When quitting with the 20k hashes it segfaults on the output.

Looking good!

[Bitweasil]

I regenerated 20k LM hashes and it loaded fine. I'll see if I can replicate some of the issue and save the LM hash list. When quitting with the 20k hashes it segfaults on the output.

Yup. Just noticed and fixed that segfault about 20 mins ago.

Output to file & output notfound work properly now, also the final hash list printing is a ton faster now (it was "not optimal" in the RC).

I just made a few tweaks to improve performance:
- If there are multiple GPUs in the system, all GPUs except GPU0 wait a second to start in. This allows the fastest GPU (CUDA ID 0) to always get the workunit on single workunit tasks - previously it went to whoever requested first.
- On Fermis, the system now automatically uses the large 512MB bitmap. This is the "-l" flag - it's automatic on Fermis, as they all have enough memory.

[Bitweasil]

Join me in #cryptohaze on freenode if you're actively debugging! I'd be glad to chat more realtime about bugs you're finding.

[Bitweasil]

--daemon mode added, very minimal output.

I think I fixed the network client segfault after reconnect a few times.

[grutz]

Cool. I let it run on a large LM hash with 1 network client and after 2:30 hours both client and server segfaulted. Lesser amounts had no problem. When you feel like cutting a new test version I'll run it through the same paces. It sounds like you've fixed a lot of the bugs already.