[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050901031457.GA15770@xs4all.nl>
Date: Thu, 1 Sep 2005 05:14:57 +0200
From: dvorak <dvorak@...all.nl>
To: john-users@...ts.openwall.com
Subject: Re: Using john des routines for 3des (or straight des) cracking
> > do you have some pointers on how to convert the john des routines
> > so that they can be used to bruteforce 3des-ede mode (or just
> > straight des)
> The only full implementation of DES encryption found in John is
> non-bitslice, and it has more than full DES functionality in it (that
> is, it can also do crypt(3) salts, which you don't need). It's the
> functions defined in DES_std.c, with some comments on them in DES_std.h.
> You would need to set DES_count to 1 and the salt to 0. You may find
> some examples of (ab)using these routines like that in AFS_fmt.c, as
> well as in BSDI_fmt.c's complicated key setup. But this stuff is real
> slow compared to the bitslice implementation.
What is missing from the bitslice implementation?
Just decryption and the permutations?
> There's no DES decryption implementation in John, so in order to
> implement 3DES-EDE, you'd have to implement DES decryption first by
> hacking one of the implementations of DES encryption.
>
> If you care about performance, you should be using the bitslice DES
> implementation, but it is incomplete (only the bits which were needed
> for the hashes supported by John are implemented). In particular,
> there are no initial/final permutation functions that would be readily
> usable with the bitslice DES implementation. You shouldn't need FP
> since you'd want to undo it when loading your DES ciphertexts. IP is
> implemented with DES_std.[ch]'s DES_do_IP() and DES_raw_get_binary().
> You may define an equivalent of DES_raw_get_binary() for your encoding
> format and use that. Notice how DES_bs.c's DES_bs_get_binary() uses
> DES_std.[ch]'s DES_raw_get_binary().
I think the permutation are not needed since they should cancel each other
out in ede mode.
basicly it should do
input -> 3des-ede-decrypt -> compare to something
input and the something can be pre-permutated.
And decryption should only be a change of order in the subkeys used so
with some luck i can find that.
> If you care about neither performance nor portability, it would be
> easiest for you to use OpenSSL DES routines. Their performance is
> similar to that of the non-bitslice DES implementation found in John
> (but you might not be able to save the IP/FP overhead like John does).
> You can still use John core to supply candidate passwords to try since
> you're not going to search the 3DES keyspace exhaustively.
OpenSSL routines are way too slow (in my tests they spent about 40-50%
in the key setup phase, presumable john is much faster in this.
thanks for the response in case i am able to get something useable i'll
post an update here.
gtx,
dvorak
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.
