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 16:57:04 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Bit slice implementation of DES based hashes

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

Powered by blists - more mailing lists

Your e-mail address:

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