[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jan 2012 19:48:41 +0530
From: Piyush Mittal <piyush.cse29@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Bit slice implementation of DES based hashes
Hello,
1. In this piece:
>
> if (LM)
> k = DES_bs_all.KS.p;
> else
> k = DES_bs_all.KSp;
>
> replace "LM" with "flags" (that is, if any flag is non-zero, use KS.p).
>
> 2. On this line:
>
> if (LM) bit = DES_LM_KP[bit];
>
> replace "LM" with "flags & 1".
>
> 3. In this place:
>
> if (LM) {
> for (c = 0; c < 0x100; c++)
> if (c >= 'a' && c <= 'z')
>
> replace "LM" with "flags".
>
> That way, you do not need to modify any existing calls to DES_bs_init(),
> but your new call will pass "2" for the flags, thereby achieving
> behavior that neither LM == 0 nor LM == 1 did before. Specifically,
> after a call like this you'll be able to use a revision of
> DES_bs_crypt_LM() like I think you're trying to, but it won't have any
> LM key setup specifics (except for the implementation detail on which
> array the key bit pointers are in).
>
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?
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?
--
Piyush Mittal
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.
