Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Jun 2006 08:42:24 +0200
From: "Otheus (aka Timothy J. Shelling)" <otheus@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: beta MPI john patch against 1.7.2.

Solar, thanks for the in-depth reply... Just a few notes...


Yes, there were rejects on the Makefile, even with "patch -l".  I had to
> fix those manually and re-generate the patch before placing it for
> download.  Please use the following command for generating patches for
> subsequent revisions of your code:
>
>         TZ=UTC diff -urp john-1.7.2 john-1.7.2-mpi >
> john-1.7.2-mpi-tjs-2.diff
>
> The "-2" will be the patch revision number - you'll increment it each
> time you generate a new patch for the same base version of John.  If you
> add any new files, you'll need to add the "-N" option to diff as well.


Understood.

Also, your john.conf has lots of unrelated changes.  It is a good idea
> to revert those.


User notes: "the john.conf provied should be *incorporated* into your
john.conf."
SHould I maybe provide a patch to john.conf in this case?

The same suggestions apply to any other patches I place in contrib/ -
> which is why I am posting them to the mailing list.
>
> > Known bugs:
> >  o   john.pot gets littered with extraneous output, usually low integers
> > like "4" or "1" and a newline. Very strange. Still trying to track it
> down.
>
> My previous guess (from the private e-mail) proves correct - you do in
> fact close stdout and stderr in your patch.  While you try to re-open
> stderr, the way you do it is not guaranteed to work right.  And I don't
> see you re-opening stdout at all.  So those numbers are some debugging
> output being printed to either stdout or stderr - perhaps they are
> MPI_rank's?


I knew you would bring this up --it's a red herring. I added that code only
late last night while I was doing some fine-tuning with the option parsing.
I t cnanot possibly have anything to do with the earlier behavior. I and I
don't close stdout (except in --test) mode, where it's irrelevant.



>  o  internalized computing the checksum for ext_word. 15% increase in
> speed
> > (at least)
>
> >  o   use of external filter with internal checksum causes a slight
> (1-2%)
> > slowdown
>
> You can't reasonably speak of speedups/slowdowns by a certain percentage
> unless you mention the hash type and the number of different salts for
> which you did your benchmarks.


--incremental mode, salted DES3.


On Wed, May 31, 2006 at 11:30:14PM +0200, Otheus (aka Timothy J. Shelling)
> wrote:
> > On synchronizing crypts/salts between all tasks, another thought
> occurred to
> > me.  After every checkpoint, simply load in the john.pot file (assuming
> it's
> > not corrupted ;) ). Would that be a simpler, (though slightly less
> optimal),
> > approach?
>
> Yes, that would work - as long as you have that file shared between the
> tasks anyway.


It is shared. Is there a function which rebuilds the database using the new
john.pot file and restarts the word--generation, etc?

I'll address optimization stuff more as a I get the chance.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ