Date: Mon, 23 Jul 2012 17:41:58 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: mscash2 / hmac-md5 ambiguity >From: Alexander Cherepanov [mailto:cherepan@...me.ru] >But, as Frank pointed out, it's better if --format is not required -- >less chances that a user will forget it. Probably we can ignore it until >we actually meet hmac-md5. That's easy. Simply use core JtR with only 5 or 10 possible formats, never try to crack anything beyond that, and you will have no problems at all ;) I think we are now pushing over 120 formats, written by different people. Numerous of these formats handle data in multiple ways, and/or handle/convert raw hash strings as valid data. That is where ambiguity creeps in. There is absolutely no way around the ambiguity. It simply is not going to happen, unless we force a unique string for each format, and that will force users to have to modify the 'native' hash strings they have in hand, just to fit into JtR. It is pretty hard (impossible) to go with no -format, if presented with 32 byte hex strings. It could be 1 of millions of different types hashes. Or what would be a 40 byte hex string. Again, same issue. The first (32 byte hex) could be: md5($s.$p) md5($p) md5(md5($p)) md5(sha512($p).$s) md4(sha512($p).$s) chop_low_16_bytes(sha512($p)) etc, etc. If that is what is native ITW, but none of them are compatible with each other, then it is up to the user running JtR to specify what method was used, and of course, JtR would have to support the hash. It is a good goal to try to remove some of these issue, and CERTAINLY to have the 'default' representation be the most often seen ITW. I currently think we have the wrong 32 byte hex 'default'. It picks LM. That is due to it being LM in the core JtR. But in the wild is NTLM or raw-md5 more likely to be seen, for 32 byte raw hex? I think so, but right now JtR defaults to LM. Sorry, I will hop off the soapbox now. Jim.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ