Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Jul 2012 02:42:42 +0400
From: Alexander Cherepanov <>
Subject: Re: mscash2 / hmac-md5 ambiguity

On 2012-07-24 02:41, jfoug wrote:
>> From: Alexander Cherepanov []
>> 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.

You are talking about formats found ITW but 
$DCC2$10240#chatelain#e4e15fdfafc8e715da9edec3611bfbff is internal 
format of john and could be chosen so as to avoid collisions.

IIUC hmac-md5 is also found ITW as two separate parts not concatenated 
with the number sign.

So the question is not whether we can do without --format with a given 
files. Rather it's whether we can convert given files to a form which 
permit omitting --format. And we almost there: --show=left do it. But 
not quite as it turns out.

> 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

Isn't NTLM usually found in pwdump format (i.e. in other field than 
other types of hashes)?

> 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.

Alexander Cherepanov

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.