[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130704064048.GA8691@openwall.com>
Date: Thu, 4 Jul 2013 10:40:48 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Using JtR to generate tripcodes
On Wed, Jul 03, 2013 at 10:30:58PM +0200, Truls Edvard Stokke wrote:
> Users of text/imageboards frequently search for novelty tripcodes (i.e.
> tripcodes with certain phrases in them), usually this is done by generating
> a very large number of them and then running the output versus a regex or
> something to that effect (which is why I can't just keep them in the binary
> format).
>
> To that goal I would like to use JtR (or at least some part of it) to
> generate a lot of them.
JtR can crack DES-based tripcodes fine, but searching for novelty
tripcodes is a somewhat different task, which JtR is not well-suited
for. What do you not like about the existing tools that readily do what
you need? What extra do you hope to achieve by using JtR? What
performance do they achieve at this?
> From what I can tell it's possible to modify the DES_bs_get_hash function
> (DES_bs.c:331 john-1.8.0) to extract all the 64 bits required to get a
> result on the same form as what DES_bs_get_binary (DES_bs.c:281 john-1.8.0)
> returns from a cipher text, and I assume all the information from the
> cipher text is retained in the binary format, but I don't know how to go
> from the binary format to the cipher text.
You could implement that, yes. You would need to extract the 58 bits
that tripcodes actually use, perform DES final permutation, and finally
perform the crypt(3)-style base 64 encoding and the regexp check (or
whatever). However, that would reduce performance a lot. Normally,
bitslice DES produces many ciphertexts at once, and they're compared
against those loaded for cracking with an efficient algorithm that does
not require processing each of the computed ciphertexts individually.
As you can see, what you're trying to do is just that - processing of
each of the computed ciphertexts individually - and it'd slow things
down a lot.
Alternatively, you could keep some of these final steps reversed, but
then you can't do e.g. a direct regexp check - you need to implement a
pre-check for would-be-good-looking tripcodes working from their
intermediary form (such as prior to DES final permutation) and in a
vectorized manner (so that you would not have to process each of them
individually). It's a challenging task, and I'm not available to help
you with it (sorry!)
To summarize: if you wanted to do this due to JtR's performance at
tripcodes, you won't achieve that with the straightforward approach, and
the better approach is complicated. So you're probably out of luck.
> I am wholly unfamiliar with DES, where do I go from here?
The only thing you'd need to know about DES is its final permutation.
You also need to understand the concept of bitslicing - see Eli Biham's
paper for that.
Good luck! (And I'm afraid that you're on your own with this...)
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.
