[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060206030856.GA4185@openwall.com>
Date: Mon, 6 Feb 2006 06:08:56 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: DIGEST-MD5, dominosec optimization (was: IPB2, DIGEST-MD5, salted domino)
On Mon, Feb 06, 2006 at 03:26:53AM +0100, Michal Luczaj wrote:
> Your're right; JtR's main site shouldn't be hosting every, err,
> experiment. If someone need it, he'll find it... or write by himself.
Actually, maybe I should set up a separate web page for "experiments"
like that.
I wrote:
> > I mean, the algorithms and code used in unofficial patches
> > for John are not really optimized anyway. You can likely achieve much
> > greater speedups by optimizing the source code.
>
> I'd love to! Any hints? :)
I won't spend much time on this discussion since the time would be
better spent actually optimizing the code and integrating it into John.
However, the really quick hint - and one which applies to other patches
as well - would be for you to be trying multiple candidate passwords in
parallel. You have this piece of code:
*pt ^= lotus_magic_table[j+t];
t = *pt;
pt++;
You can replace it with:
t1 = *pt1 ^ lotus_magic_table[j + t1];
t2 = *pt2 ^ lotus_magic_table[j + t2];
*pt1++ = t1;
*pt2++ = t2;
> > Yes, I might be forced to introduce something like that eventually, but
> > not for that reason. "configure" scripts are not expected to guess gcc
> > optimization options; they accept CFLAGS from the environment.
>
> I see. So what for this ./configure-like thingie would be used?
I'm not sure I understand your question. Are you asking whether I would
use GNU autoconf? If so, I am not sure yet. I have not yet made the
determination to implement a ./configure for John at all - but there are
some things which might force me to do that, despite the disadvantages
this has. :-(
Among those "things" is the need to pass weird options to recent
versions of gcc to get decent performance of DES-based hashes on Alpha:
"-finline-limit=2000 --param inline-unit-growth=2000". If I don't do
that, then the performance is almost twice worse than it used to be with
gcc 2.95.x and earlier. Since gcc 2.x does not support such options and
future versions of gcc might not have the "inline-unit-growth"
parameter, I cannot just embed the options in the Makefile
unconditionally. Maybe I will invent a workaround for this, e.g. use
cpp macros instead of the functions that must be inlined.
(Yes, with recent gcc it is no longer sufficient to use the "inline"
keyword and pass -finline-functions to gcc to get the functions inlined.)
--
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.
