[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 3 Sep 2014 09:50:48 -0500
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: Cracking HSRP MD5 authentication "hashes"
-----From: Dhiru Kholia Wednesday, September 03, 2014 3:58
>On Wed, 3 Sep 2014, Solar Designer wrote:
>> Can't you make this a "dynamic" mode, though? This would both avoid
>> the need for a new C source file, and run faster (can use SIMD right
away).
>>
>> I just took a look at hsrp_fmt_plug.c and I think this could probably
>> be expressed in terms of Jim's existing dynamic formats interface.
>
>Jim is already on it (http://tinyurl.com/HSRP-discussion).
I had to create a custom function for this. This format is strange. It is
this:
md5(pad_md64($p).$s.$p) The pad_md64 is a proper 'buffer' for MD5, but it
is not sent to MD5_Final. It contains the high bit set (the 0x80 after the
password), and length of bits in the last 8 bytes of a %64==0 sized null
padded buffer. Then to that unprocessed buffer, the salt and password are
again appended, then the resultant buffer is run through MD5.
So until I added that buffer-padding logic, there was not a way to do this
format in dyna. Also, the salts appear to be largely made up of null bytes.
I 'believe' this can be handled in dyna, I am just not 100% sure it is
handled 100% cleanly. I believe that dyna does 'late' $HEX$ removal if
there is NULL bytes intermixed in the salt. I simply have not had time to
view all the nuances. It may be that hashes are not removed if they are
already in a .pot file, or some other tricky stuff that we get into when we
have to modify salts.
Yes it is being put into dyna. It uses the 'flat' SIMD model, which builds
flat buffers (can handle up to 256 bytes of 'flat' buffer space, and then
performs the SIMD MD5 operations required (2 or 3 limbs). I know there will
be issues I have to work through. I will have to sort and order these (I do
not think dynamic can that now), since length of passwords will deem if this
is a 2 or 3 limb MD5. I will have to group all 2 limb and all 3 limb
passwords, packing them into the SSE-PARA sized groups. I had to do this on
some other format recently (do not remember which one), but that was not
dynamic. So this may still have to be handled with an external .C file (thin
format), and that extra logic will be put into that file, and simply use
dyna to process. The current code works fine (the .C file Dhiru wrote),
since it uses CTX model to process 1 hash at a time. If one password uses 2
limbs, and the next 3, then that is not a problem. But when you get into
intermixed SIMD code, you pretty much need to have all grouped items to have
the same processing.
So yes, I have started this as a POC within dyna, BUT it is not prime time
ready.
Also, I am not sure just how prevalent this format is, or if it is even
still in the wild. The RFC is from '95 so this is pretty much antique as
far as computing is concerned.
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.
