[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110918082524.GA24160@openwall.com>
Date: Sun, 18 Sep 2011 12:25:24 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: recent and planned changes in main tree (was: 1.7.8 Jumbo-6)
magnum -
On Sat, Sep 17, 2011 at 07:06:20PM +0200, magnum wrote:
> BTW we also included your own john-1.7.8-external-events.diff, I see
> it's not included in core.
Yes, because I was not fully comfortable with the approach taken in that
patch. It had the advantage of having no performance impact, but having
the process aborted just like by a Ctrl-C keypress felt wrong. It meant
that external modes would need to guess the amount of crypto-related
buffering and try this many extra candidate passwords before requesting
an abort.
Due to your reminder, I've just implemented the feature differently, and
this new and official implementation is now committed to the main CVS
tree, along with an update to doc/EXTERNAL. With it, when an external
mode sets "abort = 1;", all previous values of "word" that the external
mode could see are tried before the abort takes effect.
I also implemented "status". If there's any interest, we may also add
"guesses" - e.g., to let an external mode abort a session when there are
too few guesses per words tried (e.g., fewer than 10 guesses per the
last 1 million of candidate passwords).
> ? propos core... how about the revised Incremental mode everyone is
> hoping for? Can we expect getting that within this year?
Yes.
> Perhaps you
> could at least share the experimental contest version somewhere?
I can definitely share it with you as a key developer, but I am unhappy
about fully releasing it.
> What problems was found with it?
Those were not exactly "found" - we knew it was a quick hack with many
limitations from the start. For example:
When revising incremental mode, I did not add any backwards compatibility
code to let old sessions (using the previous incremental mode revision)
to be restored. Moreover, there's no safety against such attempts -
those sessions will appear to be restored (if the old .chr files are
provided), but will not work correctly (corrupting the .rec files).
The new "--fork=N" feature does not allow one to easily restore such a
forked session. This was OK for the contest, which was limited to 48
hours anyway, but it would be unacceptable for a released version.
Alexander
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.
