[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130608043305.Z3X05.557461.imail@eastrmwml107>
Date: Sat, 8 Jun 2013 4:33:05 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: limits within mscash2
I am not sure why we have user name length and password length limits within the mscash2 format? I plan to remove them, but at first, only on the CPU format.
The password is ONLY used making the NT part of the hash (simply do an MD4 on the UTF16LE of the password). This is done (at least in the CPU version) using oSSL, so there should be NO limit on the pw length. A 125 byte max JtR password length should be fine, and there is zero hit on speed.
As for the user name (salt), it is used 1 time prior to the pbkdf2, to create the dcc1 of the hash. Again, done in oSSL code, so there should be no restrictions on length. It is also used one time, within the pbkdf2, prior to the 'inner' loop. It is actually used in round 0 of the inner loop, but within our code, we have pulled that loop out. So again, putting a size limit here, can pretty much be done away with.
So from a cursory look at the code, there should be no reason at all, not to extend the pass length from 27 bytes, to 125 bytes, and extend the use name (salt) from 22 bytes, to 128 bytes.
I only plan on doing this for CPU at this time, but since the mscash2_valid() unified valid() function, takes an int,that is the salt length, I think this change can easily be made ONLY on the CPU version, then moved into GPU versions later, if it can easily be put there.
NOTE, I have not started yet, but think it should be trivial. I did make some test strings using pass_gen.pl, AND used my dcc2_tst.c file from the wiki ( http://openwall.info/wiki/john/MSCash2_simple_code ) and things appear to be very trivially extensible to the longer strings.
Jim.
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.
