Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Dec 2011 00:41:24 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Making a thread safe implementation of bitslice DES

On Thu, Dec 29, 2011 at 03:15:18PM -0500, Jordan Bradley wrote:
> Hmm those may be of use to me, thanks.

Now that I've updated JtR's own trip_fmt.c to use the bitslice DES code
(in john-1.7.9-fastrip-1.diff), wouldn't it be best for you to just use
it or build upon it - e.g., add distributed processing capabilities on
top of JtR?  The latter would even have uses beyond tripcodes.

And trip_fmt.c in JtR will continue to improve (I have specific future
changes in mind).

> For the first one you linked you 
> said it doesn't ignore DES block bits that come from the 3rd output 
> character, would that mean that the third character put into the buffer 
> would be incorrect? If so that won't be a problem since the first three 
> characters of the result are ignored anyways. if not could you explain 
> what that means a bit more plainly? I know very little about 
> cryptography (as you've probably guessed).

What buffer?  Like I tried to explain before, JtR never generates those
ASCII strings.  During cracking, it deals with binary representations of
things.

When I said that BitRipper (the source code on GitHub) doesn't appear to
ignore those bits I meant that the following likely happens:

1. The program loads tripcodes into memory.  These have 58 bits of data.

2. The bitslice DES code computes full 64-bit ciphertexts, including the
6 bits that are not part of tripcodes.

3. The program compares those 58-bit and 64-bit values.  For most
passwords, they won't match even if the password is correct.

This is based on my quick glance at the source code only.  I could be wrong.

Indeed, trip_fmt.c in JtR deals with this problem.  It's not difficult,
but also not trivial because the exact locations of the 6 bits prior
to DES final permutation (which is undone at load time) are not
immediately obvious and because when using the non-bitslice code the 64
bits are spread over a 128-bit set of variables for
implementation-specific reasons (and how exactly they're spread varies
between builds of JtR).  See the memset()'s of some DES_bs_all.B[]
elements (bitslice) and the binary_mask stuff (non-bitslice) - both in
trip_fmt.c as patched with john-1.7.9-fastrip-1.diff.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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