Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Apr 2013 07:47:36 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: revised incremental mode and charset files

On Sat, Apr 27, 2013 at 03:08:05PM +0400, Sergey V. wrote:
> I did some short test from fresh git unstable branch (commit fc8c9fd7). Seems
> new incremental mode works fine.

Thanks!  Yet I've since found and fixed some bugs in it - some of them I
was actually able to trigger.  I hope I have not introduced more bugs in
the process, but more testing is desired.

magnum, can you merge the changes I've just pushed to the public CVS?
(It is OK to omit the --node stuff for now if you prefer.  I expect to
revise it with further commits today anyway.)

Sergey and all, can you do some more testing of the new incremental -
either after magnum confirms he has merged the latest changes, or using
CVS code directly (not jumbo)?  One of the (obvious) tests is to make
sure it produces no duplicate passwords, and that it produces an
exhaustive list of passwords for a small enough password space (I was
using -i=digits, but it's better if you use something else - so that the
coverage by our team-wide testing is greater).

Another test is to measure its efficiency vs. the old incremental mode,
when both are trained in the same way.  The new incremental should
perform better (crack more passwords in the same time while achieving
similar c/s rate).

Yet another test is to measure its efficiency vs. the contest edition's
(for those of you who have it) - the new incremental should perform no
worse or maybe slightly better (same efficiency for a given number of
candidates tested, but a higher c/s rate when running against fast hashes).

> Should I do test more long sessions (with more big MaxLen and CharCount)?

Not necessarily that.  For example, two of the bugs (now fixed) would
show up with smaller rather than larger settings - in particular, when
having very little input data in john.pot from which a .chr file was
generated.  There may be more bugs triggerable with extreme settings
like that - and it could be extreme smalls and/or extreme larges, or
mixes thereof.  Non-extreme settings are also relevant, indeed.

> Also, progress indicator is always shows 0:00%, it is correct?

This is jumbo-specific, so I don't care yet. ;-)  But you may. ;-)

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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