Date: Mon, 23 Jan 2012 23:02:47 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Bit slice implementation of DES based hashes On Mon, Jan 23, 2012 at 10:40:33PM +0530, Piyush Mittal wrote: > I am not talking of SSL Des, I am considering bitslice Des that I am > making, In that I am calling DES_bs_set_key() using the key > "\x80\x11\x22\x33\x44\x55\x66\x77" (after parity drop) as you told me in > previous posts. But here my question is that why we have taken this key > after parity drop? Even though we have already used parity drop in > DES_bs_init() ? That's how I understood your question and I already provided a response to it in the previous message. (I went further and also commented on the other instance of "set key" that you'd need to deal with for Oracle hashes.) OK, let me try to explain the parity thing in a lot of detail. A DES key with parity is 64-bit, of which 56 are significant. A DES key without parity is 56-bit. Under various programming interfaces, these keys may be passed e.g. as arrays of 8 char's or as NUL-terminated strings of up to 8 chars. Some of these may discard the least significant bit in each char (OpenSSL's does this), some may discard the most significant bit of each char (JtR's own DES_bs_set_key() does this, with the extra detail that the value 0x80 is special). (Also, some may accept arrays or strings of 7 8-bit chars instead - DES_bs_set_key_LM() does that. But it's irrelevant right now.) There's not exactly a "parity drop in DES_bs_init()". This function merely initializes key bit pointers to point to actual key bits. There's no reasonable way it could possibly use parity bits. In oracle_fmt_plug.c: oracle_init(), we have the constant key specified with the unused "parity" bits as the least significant bits. This is consistent with the call to OpenSSL's DES_set_key(). (I put "parity" in quotes because the bit values specified there are not actually correct parity. They're arbitrary.) We need to pass this same key into DES_bs_set_key(), which discards the most significant bits instead. So we shift each char right by 1 bit, thereby shifting out the unused "parity" bits and shifting in zero bits (into the most significant bits of each char). We could as well shift in one bits - in fact, we do just that for the char that would otherwise be NUL. Those bits are unused anyway, except that a NUL would terminate the strings with the DES_bs_set_key() interface. Is this clear now? 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.