[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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 1.7.3.1
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.
