[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141218173408.GA2866@openwall.com>
Date: Thu, 18 Dec 2014 20:34:08 +0300
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com, john-users@...ts.openwall.com
Subject: John the Ripper 1.8.0-jumbo-1
Hi,
After over 2 years of development since the 1.7.9-jumbo-7 release, a new
"community-enhanced" jumbo version of John the Ripper is finally out:
http://www.openwall.com/john/
John the Ripper 1.8.0-jumbo-1 is based on today's code from the
bleeding-jumbo branch on GitHub, which we've tried to make somewhat
stable lately in preparation for this release.
You may notice that the source code archive size has increased from
under 2 MB to over 20 MB. This is primarily due to the included .chr
files, which are both bigger and more numerous than pre-1.8 ones.
There are lots of source code additions, too. In fact:
This is probably the biggest single jumbo update so far. The changes
are too numerous to summarize - unfortunately, we haven't been doing
that during development, and it'd be a substantial effort to do it now,
delaying the release to next year. So we chose to go ahead and release
whatever we've got. (Of course, there are the many commit messages -
but that's not a summary.)
A really brief summary, though, is that there are new "formats" (meaning
more supported hash and "non-hash" types, both on CPU and on GPU),
various enhancements to existing ones, mask mode, better support for
non-ASCII character sets, and of course all of 1.8.0's features
(including --fork and --node). And new bugs.
Oh, and we're now using autoconf, meaning that you need to "./configure"
and "make", with all the usual pros and cons of this approach. There's
a Makefile.legacy included, so you may "make -f Makefile.legacy" to try
and build JtR the old way if you refuse to use autoconf... for now...
and this _might_ even work... but you'd better bite the bullet. (BTW, I
have no current plans on autoconf'ing non-jumbo versions of JtR.)
Due to autoconf, things such as OpenMP and OpenCL are now enabled
automatically (if system support for them is detected during build).
When this is undesirable, you may use e.g. "./configure --disable-openmp"
or "./configure --disable-openmp-for-fast-formats" and run with --fork
to achieve a higher cumulative c/s rate across the fork'ed processes.
Out of over 4800 commits since 1.7.9-jumbo-7, over 2600 are by
magnum, making him the top contributor. Other prolific contributors are
JimF, Dhiru Kholia, Claudio Andre, Frank Dittrich, Sayantan Datta.
There are also multiple commits by (or attributed to) Lukas Odzioba,
ShaneQful, Alexander Cherepanov, rofl0r, bwall, Narendra Kangralkar,
Tavis Ormandy, Spiros Fraganastasis, Harrison Neal, Vlatko Kosturjak,
Aleksey Cherepanov, Jeremi Gosney, junmuz, Thiebaud Weksteen, Sanju
Kholia, Michael Samuel, Deepika Dutta, Costin Enache, Nicolas Collignon,
Michael Ledford. There are single commits by (or attributed to) many
other contributors as well (including even one by atom of hashcat).
time ./john --test
[...]
All 440 formats passed self-tests!
real 19m43.305s
user 83m38.966s
sys 4m26.517s
including OpenCL and CUDA "formats".
Errata:
On some AMD cards with some Catalyst versions, a few of the OpenCL
formats fail (or even lock up the GPU) - it is unrealistic for us to
include workarounds for all. The above all-passing test is from an
NVIDIA card (generally slower, but with more stable drivers). Yet we
expect that you will use AMD cards, and hopefully the formats you
will need to use will not be among those failing on your card/driver.
Enjoy, and please provide feedback via the john-users mailing list.
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.
