Date: Sun, 24 Jun 2012 12:40:57 -0700 (PDT) From: deepika dutta <deepikadutta_19@...oo.com> To: john-dev@...ts.openwall.com Subject: Re: mschap-v2 conversion ok now i understood, i think using 0x80 will be fine instead of having a separate function. Cheers, Deepika ________________________________ From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Sent: Monday, June 25, 2012 12:48 AM Subject: Re: [john-dev] 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 Content of type "text/html" skipped
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.