[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Jun 2012 23:18:10 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: mschap-v2 conversion
Hi Deepika,
On Sun, Jun 24, 2012 at 11:49:03AM -0700, deepika dutta wrote:
> Hi, I looked into the problem, the testsuite is fine. Problem is with the DES_bs_set_key() function where each byte of key is being checked for 0 and if some byte is found to be 0, all the next key bytes are taken to be 0.
As discussed with Piyush before, my suggestion was to use 0x80 in place
of 0 for this very reason. This is what the constant key in Piyush's
patch uses (it would contain a 0 otherwise). The same trick is also
used in the core JtR tree in BSDI_fmt.c: set_key():
*chr++ = 0x80 |
((block[word] >> (1 + (pos << 3))) ^ *ptr);
(The resulting key is passed to non-bitslice DES code there, though,
but the "set high bit to protect 0 octets" idea is the same.)
> I removed the check for 0 from DES_bs_set_key() and ran the test suite, it was successful for all 1500 cases. I don't understand the need for this check for 0 of each key byte, whether this can be removed?
This shouldn't be removed from DES_bs_set_key() itself because normal
Unix passwords are NUL-terminated strings. However, as an alternative
to the 0x80 approach suggested above, you may create a copy of
DES_bs_set_key() under another name and with the check for 0 removed -
and use that.
Thanks,
Alexander
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.
