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.