[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111229204124.GA11902@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
