Date: Wed, 9 Nov 2011 19:17:29 +0400 From: Solar Designer <solar@...nwall.com> To: announce@...ts.openwall.com, john-users@...ts.openwall.com Subject: [openwall-announce] John the Ripper 1.7.8-jumbo-8 Hi, [ Offtopic: anyone with a "permanently failed" MacBook battery (doesn't charge, shows as "Poor" or "Check battery" in the GUI)? E-mail me off-list if you don't mind trying a software repair on it (so far tested on my battery only, with success). No promises, not a free support offer, ABSOLUTELY NO WARRANTY. And yes, this builds upon Charlie Miller's research and code. ] I've just released John the Ripper 1.7.8-jumbo-8: http://www.openwall.com/john/ Most of the changes since -jumbo-7 are by magnum and JimF - thanks! My role was mostly limited to preparing the release, although I've also added a couple of Perl scripts. Also, there's a new Perl script by Jean-Michel Picod. Here's more detail on the changes: * Optional OpenMP parallelization has been added for MD5-based crypt(3) and Apache $apr1$ hashes when building with SSE2 intrinsics, as well as for SAP CODVN B (BCODE) and SAP CODVN G (PASSCODE). (magnum) * Raw MD4 has been enhanced with optional SSE2 intrinsics. (magnum) * The SSE2 intrinsics code for MD4, MD5, and SHA-1 has been pre-built with Intel's compiler into an assembly file, used with the new linux-x86-64i, linux-x86-sse2i, and win32-mingw-x86-sse2i make targets (these i-suffixed targets use gcc and do not require icc to be installed, yet benefit from the pre-compiled code). (magnum) * A CRC-32 "format" has been added (see comments and samples in crc32_fmt_plug.c for proper usage). (JimF) * Support for occasional false positives or multiple correct guesses has been added and made use of for WinZip/AES and CRC-32. (JimF) * "md5_gen", which was not limited to MD5 anymore (also supporting SHA-1 based hashes now), has been renamed to "dynamic". (JimF) * Two Perl scripts have been added to dump password hashes from Mac OS X 10.7 (Lion) binary plist files - lion2john.pl, lion2john-alt.pl (normally only one of these is required). (Solar, JimF, Jean-Michel Picod) * A Perl script has been added to compare two sets of benchmarks (saved "john --test" output) - relbench.pl. (Solar) * Numerous other fixes and enhancements have been made, including to character encodings support and to status reporting (such as to emit a status line at every cracked password and to show number of candidates tried in the status line). (magnum, JimF, Solar) Speaking of the OpenMP parallelization and intrinsics, here are some benchmarks on 2xE5420 2.5 GHz, gcc 4.5.0, "make linux-x86-64i": Benchmarking: FreeBSD MD5 [12x]... (8xOMP) DONE Raw: 215040 c/s real, 26812 c/s virtual Benchmarking: SAP BCODE [sapb]... (8xOMP) DONE Many salts: 10166K c/s real, 1267K c/s virtual Only one salt: 7737K c/s real, 964788 c/s virtual Benchmarking: SAP CODVN G (PASSCODE) [sapg]... (8xOMP) DONE Many salts: 6948K c/s real, 867475 c/s virtual Only one salt: 5061K c/s real, 631062 c/s virtual Also curious (at least to me, although I am biased) is the benchmark comparison script, relbench.pl. With 1.7.8-jumbo-8, "john --test" reports as many as 160 individual benchmark results. Often it is not clear whether a certain change - different JtR version, compiler, compiler options, computer - makes things faster or slower overall, by how much, and how much this varies by hash/cipher type. Although for your own immediate use you probably care about just one or a handful of benchmarks, when some of us build John the Ripper packages for others to use we care about overall performance. Also, being able to compare different JtR builds like this helps a certain secondary use of JtR: as a general-purpose benchmark (for C compilers, their optimization vs. security hardening options, OpenMP implementations, CPUs, computers). For example, here's how Pentium 3 at 1.0 GHz (gcc 3.4.5, linux-x86-mmx) compares to one core in E5420 2.5 GHz (gcc 4.5.0, linux-x86-64i, no OpenMP), both running 1.7.8-jumbo-8: $ ./relbench.pl 1.7.8-j8-mmx 1.7.8-j8-64i Number of benchmarks: 160 Minimum: 1.90200 real, 1.90200 virtual Maximum: 19.68295 real, 19.68295 virtual Median: 4.08437 real, 4.08439 virtual Median absolute deviation: 1.25943 real, 1.25940 virtual Geometric mean: 4.85750 real, 4.85302 virtual Geometric standard deviation: 1.57265 real, 1.57344 virtual This shows that speedup varies from 1.9x to 19.7x, with median and geometric mean at around 4.5x. Another set of tests shows that gcc 4.6.2's -fstack-protector does not result in a slowdown, whereas -fstack-protector-all has a 1.2% slowdown: $ ./relbench.pl asis ssp Number of benchmarks: 158 Minimum: 0.97152 real, 0.97152 virtual Maximum: 1.05857 real, 1.06020 virtual Median: 1.00181 real, 1.00171 virtual Median absolute deviation: 0.00516 real, 0.00593 virtual Geometric mean: 1.00311 real, 1.00367 virtual Geometric standard deviation: 1.01337 real, 1.01360 virtual $ ./relbench.pl asis sspa Number of benchmarks: 158 Minimum: 0.91182 real, 0.92094 virtual Maximum: 1.03674 real, 1.04156 virtual Median: 0.98883 real, 0.98883 virtual Median absolute deviation: 0.01139 real, 0.01172 virtual Geometric mean: 0.98710 real, 0.98765 virtual Geometric standard deviation: 1.01801 real, 1.01799 virtual (These are for -jumbo-7 on a Core 2 Duo, no OpenMP.) Of course, with performance ratios this close to 1.0, you need to run the benchmarks more than once to make sure the results are reliable. The relevant concepts are explained here: http://en.wikipedia.org/wiki/Median http://en.wikipedia.org/wiki/Median_absolute_deviation http://en.wikipedia.org/wiki/Geometric_mean http://en.wikipedia.org/wiki/Geometric_standard_deviation When interpreting the results, I recommend that we primarily use the geometric mean, but also look at the median as a sanity check. The median and the median absolute deviation are more robust when there are outliers (which the median ignores): http://en.wikipedia.org/wiki/Robust_statistics#Examples_of_robust_and_non-robust_statistics http://en.wikipedia.org/wiki/Outlier On a related note, prompted by a question on john-users, I did some research on effect of password policies on keyspace reduction: http://openwall.info/wiki/john/policy Once in a while, someone posts to john-users asking how to restrict John the Ripper to match a policy, hoping that this would substantially reduce the number of candidate passwords to try. Most of the time, such assumptions are incorrect, although in some extreme cases they are valid. For example, for printable US-ASCII (95 different characters) and length 8 requiring at least 3 character classes (out of four: digits, lowercase letters, uppercase letters, and other characters) reduces the keyspace by only 5.5% (so it is a reasonable thing to do). However, requiring at least 2 characters of each class (which for length 8 implies exactly 2 characters of each class) reduces the keyspace for length 8 by a factor of 52.9 (which in terms of keyspace reduction is almost as bad as making passwords one character shorter) and for length 9 by a factor of 17.6. Discussion on reddit /r/netsec/: http://www.reddit.com/r/netsec/comments/lfgbz/effect_of_password_policies_on_keyspace_reduction/ Finally, John the Ripper is still 10th most popular security tool out there out of 125 top tools per SecTools' latest survey, just like it was per 2006's survey: http://sectools.org http://sectools.org/tool/john/ Along with the update based on the latest survey's results, the SecTools website has been redesigned to make it more dynamic, so you may comment on and rate the tools now. (Openwall is not affiliated with SecTools, but I felt that this SecTools update was worth mentioning.) Enjoy, and please be sure to provide your feedback on john-users. 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.