Date: Tue, 16 Sep 2008 10:10:54 +0200 From: Simon Marechal <simon@...quise.net> To: john-users@...ts.openwall.com Subject: Re: jumbo patch for 18.104.22.168 Solar Designer a écrit : > domino4_fmt.c, domino5_fmt.c, domino_md.*, and the corresponding code in > x86.S - I'm not sure how this compares to lotus5_fmt.c and DOMINOSEC_fmt.c, > which are in the jumbo patch. Do these implement support for the exact > same two things or not? How does said support differ - in terms of both > functionality and performance? They implement the exact same thing. The only difference is that I have a x86 version of the ''scramble'' function. The domino version numbers are wrong for my implementation. > tightvnc_fmt.c - unused, and it looks unfinished - is that the case? Is > this something to consider for inclusion (after it is made to work)? It does not work, I can't remember when I started working in this :/ I'm currently not planning to add support to it as I never had to crack such passwords during pentests. >> * usage of the SSE functions when they are available > > Can you possibly identify those cases where you have optimized assembly > code and the latest jumbo patch does not - and post a list in here, or > maybe submit a patch (to be applied on top of the jumbo patch) right away? The SSE md5 code is almost never used here. When I have some more free time I'll write a properly optimized version of this function, and try to release patches for it. >> * a shortcut for the netlm cipher (part of the original LM hash could be >> bruteforced. It could be possible to crack it almost as fast as the >> original LM hash) > > Where is this hack found in your code, exactly? Is there any info on it > that would enable people to use it? It is in the NETLM_fmt.c file. It's mostly a PoC, and I'm not sure this works as I never have to crack such challenges/responses. The protocol is somehow described here http://en.wikipedia.org/wiki/NTLM (NTLMv1 paragraph). The idea is that the secret, either DES or MD4 hash, is cut in 3 parts, 7 bytes each. The last part is made of the last two bytes of the secret, padded with five 0's. It is thus obvious that the last two bytes of the secret can be deduced with less than 2^16 calls to the DES encrypt function. It is then possible to compute the windows hashes just as usual, to check for the last two bytes, and to only make the necessary DES calculations when they match. My patch does this for the LM hash case, which is not such a great idea, as deducing the two parts of the LM hash is now done in an asymmetric way. A good way to do this would be, for the NT hash case, to: * brute force the last 2 bytes of the MD4 in the binary() function * use an optimized MD4 implementation in crypt_all * compare the last 2 bytes in cmp_all * compare the last 2 bytes and if they match compute and compare the whole hash in cmp_one I'm not sure if this would be really useful, but a "TODO" list in the wiki could contain a list of stuff that should be done :) >> * an optimized "old lotus" implementation for x86 > > Yes. I will probably want to have this in the jumbo patch if it really > is faster. Benchmarking: Lotus5 [Lotus v5 Proprietary]... DONE Raw: 86238 c/s real, 87109 c/s virtual Benchmarking: Domino 4 [Domino 4 (RSA MD)]... DONE Raw: 300199 c/s real, 301405 c/s virtual Mine is faster, but has a wrong description :) The "proprietary" algorithm is however a RSA algorithm. It is like MD2, but with different magic numbers. I suppose it would be possible to go faster with x64, given that there are much more registers. I'll try to produce a patch for this ASAP, working for both lotus versions. -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.