Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Sep 2005 06:47:53 +0400
From: Solar Designer <>
Subject: Re: Using john des routines for 3des (or straight des) cracking

On Thu, Sep 01, 2005 at 04:02:38AM +0200, dvorak wrote:
> 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) 

There's no existing documentation on what and how to patch to make this
work.  However, here are a few hints:

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.

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().

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.

> i am looking to use the john des routines to do a single 3des
> encryption to see if the password is right, but i have trouble figuring
> out how to use those routines for straight des. 

That's because they were designed for crypt(3) and then extended to also
feature some flexibility (as used in AFS_fmt.c and BSDI_fmt.c).  I might
try to re-code things in a more generic way post-1.7.

Anyway, you do not really want to do "a single encryption".  That's
relatively slow.  If you would be doing that, you may as well use
OpenSSL routines.  For performance, you need the bitslice implementation
and it processes 32 to 128+ passwords in parallel.

> I just found the LM cracker which (according to rfc2433) does:
> desencrypt("KGS!@...", password)
> in the bit slice implementation b[x] is being setup using some
> bits, the amount of ones is 23 and so is the amount of 1's in "KGS!@..."
> the different places i attribute to the permutation step that DES
> does.
> Does the above paragraph make any sense or i am looking in the wrong
> direction?

You're absolutely correct about the above, so your chances of hacking
this code "right" are high. :-)

Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Was I helpful?  Please give your feedback here:

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ