
Date: Tue, 5 Apr 2011 04:06:17 +0400 From: Solar Designer <solar@...nwall.com> To: johndev@...ts.openwall.com Subject: Re: Using DES_bs On Mon, Apr 04, 2011 at 06:27:57PM 0500, Daniel Beard wrote: > Okay I have one last question just so I'm clear. Does DES_bs encrypt a key > to a DES hash or attempt to decrypt a DES hash to find a key candidate? Neither, and this is not specific to the implementation. Assuming that we're talking about the DESbased crypt(3), it applies DES as follows. The password is used as the DES encryption key. The data to be encrypted is 0 (a 64bit block of all zero bits). 25 iterations of saltmodified DES are used to encrypt this block. The resulting "encrypted" block is used as a hash of the password. Thus, in DES terms, the key is not being encrypted. What John does is: 1. For each DESbased hash loaded for cracking, the ASCII encoding is reversed and the DES final permutation is undone. 2. For each candidate password, it is setup as a DES key, and 25 iterations of saltmodified DES are used to encrypt the allzeroes block. Then, without doing final permutation, the result is compared against hashes loaded for cracking (and preprocessed as described above). Thus, the initial and final permutations of DES are not performed in the main cracking loop at all. First, there's no point in permuting the 64 zero bits. Then, each iteration's final permutation would be reversed by the next iteration's initial permutation. Finally, the final iteration's final permutation is undone at loading of the hashes. With a bitslice implementation, we actually produce a large number of password hashes at once (for different candidate passwords), and usually we compare them against the hashes loaded for cracking indirectly (either with the logarithmic time algorithm in DES_bs_cmp_all() or with hash table lookups, where we use partial hashes as indices). Alexander
Powered by blists  more mailing lists