Date: Wed, 8 Jun 2011 07:30:42 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Lukas's Status Report - #4 of 15 Lukas, On Wed, Jun 08, 2011 at 05:05:09AM +0200, ?ukasz Odzioba wrote: > My fault, it was ultra fast crypt(3) i sugested md5 because files was > in the same directory as md5-based crypt. ufc-crypt is des based so it > wont help. > http://ftp.sunet.se/pub/security/tools/password/ufc-crypt/ufc-crypt.tar.gz Yes, and it was only "ultra fast" on some machines from 20-15 years ago, and before the advent of bitslice DES. It might become fast again as L1 data caches become larger, though (it needs 128 KB). JtR implements the same algorithm as a compile-time option (DES_128K), but it's normally mostly unused. > > You mean to the one in JtR? BTW, bartavelle's code in 1.7.7-jumbo-5 > > introduces a SIMD implementation. > > I meant that, which is my base, which I dont like for the same reason > as sha256-based crypt version. I find this sentence confusing. > http://www.opensource.apple.com/source/tcl/tcl-87/tcl_ext/trf/trf/md5-crypt/md5-crypt.c It's fine to look at this, and also at phk's original implementation in FreeBSD, but you need to also look at the code in JtR, which already has some of the optimizations that you'll need to include as well. Specifically, you should not do all those (cnt % 3 != 0), etc. checks. Instead, you need to use something similar to the 21-entry order array that JtR normally uses for implementation of this hash type. Thanks, Alexander
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.