[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120123190247.GC21059@openwall.com>
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.
