|
Message-ID: <20050901024753.GA32482@openwall.com> Date: Thu, 1 Sep 2005 06:47:53 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com 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 openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.