[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110608033042.GA26459@openwall.com>
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.
