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.