Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ