[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120123161245.GA20620@openwall.com>
Date: Mon, 23 Jan 2012 20:12:45 +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 07:48:41PM +0530, Piyush Mittal wrote:
> According to these changes , I am getting the round keys bits but while
> retrieving them through these lines of code..
>
> for(bit=0;bit<768;bit++)
> printf("%u",(k[bit][0]));
>
> I am not getting the exact sequence of 768 bit keys.(Counter checked by an
> example taken from Book Forouzan). What is the reason behind this?
Exact sequence as what you see in the book? Is that "Cryptography and
Network Security" by Behrouz A. Forouzan?
Well, I don't readily have the answer to this. I don't have that book.
> Even though we are using parity drop in DES_bs_init() then why we need to
> apply parity drop before calling DES_bs_set_key() in oracle code?
If you're referring to oracle_fmt_plug.c: oracle_init(), then it has the
parity bits in its specified key dropped by the DES_set_key() call. We
need to implement an equivalent of this, which we may do by adjusting our
specified key value as I had proposed (no need for any runtime overhead).
Things are trickier with these lines, also in oracle_fmt_plug.c:
DES_ncbc_encrypt((unsigned char *)cur_salt, buf, l, &desschedule1, (DES_cblock *) crypt_key, DES_ENCRYPT);
DES_set_key((DES_cblock *)crypt_key, &desschedule2);
I think what you need to do here is to apply the normally-excluded (in
JtR's code) DES final permutation between these two steps.
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.
