Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Sep 2005 05:14:57 +0200
From: dvorak <>
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.


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.