[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Jun 2006 18:27:14 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: beta MPI john patch against 1.7.2.
On Fri, Jun 02, 2006 at 08:42:24AM +0200, Otheus (aka Timothy J. Shelling) wrote:
> 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?
Yes, your changes to john.conf should be a part of the patch. In fact,
the *.diff that I made public includes your john.conf changes in it.
> >> Known bugs:
> >> o john.pot gets littered with extraneous output, usually low integers
> >> like "4" or "1" and a newline. ...
> >My previous guess (from the private e-mail) proves correct - you do in
> >fact close stdout and stderr in your patch. ...
> I knew you would bring this up --it's a red herring. I added that code only
> late last night ...
OK, but that code is wrong. You should at the very least consider using
dup2() instead of dup().
> >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.
What's DES3? You probably mean the traditional DES-based crypt(3). And
you haven't mentioned the number of different salts.
I am not really asking you to provide all that information. I merely
point out that it doesn't make sense to mention specific speedup/slowdown
percentages without including that info as well.
> Is there a function which rebuilds the database using the new
> john.pot file
There's ldr_load_pot_file(). A call to it must be followed by a call to
ldr_fix_database(). Both of these were only meant to be called at
startup, so I am unsure whether they'd work right from within a running
session - that would require a code review and testing.
With large "pot files" and/or a lot of password hashes loaded, this
reload/rebuild may be rather costly, although hash tables are being used
to make it faster. You can expect 10 seconds for 100,000 hashes or so.
> and restarts the word--generation, etc?
I don't think you need to "restart word generation", but you need to
ensure that you do the database rebuild from outside of loops that
depend on the database to remain constant. Perhaps doing it at the
beginning of crk_salt_loop() is safe, but I did not verify that.
Indeed, you need to rate-limit this and also check for the database
possibly becoming empty.
--
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.
