[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Dec 2011 20:22:35 +0530
From: piyush mittal <piyush.cse29@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Bit slice implementation of DES based hashes
Hi,
> You're confused.
>
It can be.
DES keys are 56-bit. You have a 56-bit binary value for the key. You
> don't need anything else. ASCII and Unicode are irrelevant here.
>
Yes that is true but in order to use in bitslice DES interface we need
ASCII code.
Actually, the value that you have is 64-bit, but the least significant
> bit of each octet is ignored. To confirm this, I've just changed the
> line:
>
> deskey[0] = 0x01;
>
> to:
>
> deskey[0] = 0x00;
>
> in a copy of oracle_fmt_plug.c. The self-test passes.
>
> Now, to make use of the existing bitslice DES interface, you do in fact
> need to represent this binary key in ASCII. You need to shift each
> octet right by one bit (thereby dropping the unused parity bit), and if
> the resulting value would be zero (like it is in the example above), you
> need to set the most significant bit to prevent the would-be-NUL octet
> from terminating the C string.
>
Even if I drops the parity bits then remaining 56 bits are as follows
00000000010001010001001100111000100101010111001101110111
and its corresponding ASCII equivalent I am not getting.
On Sun, Dec 18, 2011 at 6:27 PM, Solar Designer <solar@...nwall.com> wrote:
> On Sun, Dec 18, 2011 at 04:38:10PM +0530, piyush mittal wrote:
> > At last a new twist came. The character equivalent of Ox0123456789ABCDEF
> is
> > a sequence of special characters i.e NON ASCII.Therefore it is mandatory
> to
> > use Unicode in oracle and then I hope we also need to change whole code
> of
> > Bit slice DES to Unicode because there every calculation is going on with
> > respect to ASCII char only .
>
> You're confused.
>
> DES keys are 56-bit. You have a 56-bit binary value for the key. You
> don't need anything else. ASCII and Unicode are irrelevant here.
>
> Actually, the value that you have is 64-bit, but the least significant
> bit of each octet is ignored. To confirm this, I've just changed the
> line:
>
> deskey[0] = 0x01;
>
> to:
>
> deskey[0] = 0x00;
>
> in a copy of oracle_fmt_plug.c. The self-test passes.
>
> Now, to make use of the existing bitslice DES interface, you do in fact
> need to represent this binary key in ASCII. You need to shift each
> octet right by one bit (thereby dropping the unused parity bit), and if
> the resulting value would be zero (like it is in the example above), you
> need to set the most significant bit to prevent the would-be-NUL octet
> from terminating the C string. While OpenSSL's DES_set_key() ignores
> the least significant bit in each octet, John's DES_bs_set_key() does
> this for the most significant bit of each octet (like DES-based crypt(3)
> does). I think you'll get:
>
> "\x80\x11\x22\x33\x44\x55\x66\x77"
>
> ...oh, I just realized that in 1.7.9+ you need to actually use
> DES_bs_set_key_LM() because DES_bs_crypt_LM(), which you'll base your
> revision on, now includes key setup finalization in it. So you'll need
> to turn the above string into a 7-character string with 8-bit characters -
> simply by placing the significant bits one after another with no gaps.
> Oh, and you'll need to drop the LM-specific DES_LM_KP[] permutation.
>
> ...As a maybe-better alternative, you may create a mix of
> DES_bs_crypt_LM() and DES_bs_crypt(), where you'd take the key setup
> finalization step from the latter. In that case, you may use
> DES_bs_set_key() with the specific key string I included above, and you
> don't need to worry about DES_LM_KP[].
>
> Alexander
>
--
Piyush Mittal
Department of Computer Science and Engineering
National Institute of Technology,Rourkela
INDIA
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.
