[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060113054421.GA19082@openwall.com>
Date: Fri, 13 Jan 2006 08:44:21 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: JtR 1.7 release candidate
On Thu, Jan 12, 2006 at 07:47:41PM +0000, Phantom wrote:
> Any chance of a changelog of this release? ;)
The changes applied since 1.6.40 are minimal. No new features or
performance improvements could possibly get in so shortly before a
"stable" release. If you're really curious, you can browse the revision
histories of individual source files via CVSweb:
http://cvsweb.openwall.com/john
Additionally, the changes are briefly described in the Owl package RPM
spec file available here:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/~checkout~/Owl/packages/john/john.spec?rev=HEAD;content-type=text%2Fplain
The last entry is:
* Mon Jan 09 2006 Solar Designer <solar-at-owl.openwall.com> 1.7-owl1
- Documentation updates: separated CONTACT from CREDITS, added some FAQ
entries, etc.
- When displaying programs' usage information, use either an equivalent of
basename(argv[0]) (with the main John program) or fixed strings (with the
auxiliary tools).
- In rec_done(), do a log_flush() even if the session completes normally;
this is needed to hopefully update the pot file prior to our removal of the
crash recovery file.
- Applied some Cygwin-specific updates to signals.c and DOS/Win32-specific
updates to the Makefile.
The most significant change this time is the very availability of
would-be official DOS and Win32 builds, -- which is precisely why I've
asked for testing of those. Would you and others please test these
builds with your typical uses of John? That is, run it on some password
files or maybe continue a session started with an older version. Then
let me know whether there were any problems.
As it relates to the major changes made since 1.6, they're documented in
doc/CHANGES, also available at this URL:
http://www.openwall.com/john/doc/CHANGES.shtml
> 1.7 (win-mmx) bench>
> Benchmarking: Traditional DES [64/64 BS MMX]... DONE
> Many salts: 992374 c/s
> Only one salt: 925581 c/s
That's really good DES performance for an x86 system. It's good to know
that you've been getting the same performance (for all hash types) with
another build (of 1.6.40), so things are pretty stable for you
performance-wise.
Here's one funny detail: I intentionally did the DOS build with an older
version of gcc (2.95.3), resulting in somewhat better LM hash
performance on at least Pentium 3 processors (maybe also on AMD ones).
Unfortunately, this older gcc is no longer available pre-built for
Cygwin, so I did not bother to do the same for Win32 (I used gcc 3.4.4
there). The real fix would be to provide x86 assembly code for parts of
DES_bs.c for the next release. This only affects LM hashes.
I did some brief benchmarks of this build of John vs. ex-@...ke's LC5
(now discontinued by Symantec), ElcomSoft's PPA, and SAMInside at LM
hashes. I am satisfied with the results. :-) (I also tried out LC5's
support for Unix hashes. It's slow and the user interface misbehaves.
Perhaps the next version would have been better, if the product were not
discontinued.)
--
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
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.
