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.