Date: Fri, 21 Sep 2012 00:10:40 +0400 From: Solar Designer <solar@...nwall.com> To: announce@...ts.openwall.com Subject: [openwall-announce] JtR 1.7.9-jumbo-7; php_mt_seed; YaC 2012 (October 1, Moscow) Hi, As the Subject suggests, this is to announce several related things at once - not just the JtR release - but I'll start with just that. 1. Today we've released JtR 1.7.9-jumbo-7. This is a bugfix-mostly release. We're deliberately not including support for new formats (even though we have plenty of those in development trees), except for a couple that slipped through (KeePass 2.x, RAdmin 2.x). (Many more new formats and other goodies will be in a future release.) You may download John the Ripper 1.7.9-jumbo-7 at the usual location: http://www.openwall.com/john/ Direct code contributors to 1.7.9-jumbo-7 (since 1.7.9-jumbo-6), by commit count: magnum JimF Frank Dittrich Claudio Andre Dhiru Kholia Solar Designer Lukas Odzioba myrice (Dongdong Li) Sayantan Datta Knug Carl Gustf Vlatko Kosturjak Tavis Ormandy Pavel Semjanov Elijah [W&P] Erik Winkler High-level overview of the changes: * KeePass 2.x support (in addition to 1.x) (Dhiru) * The dynamic formats support has been enhanced a little bit, and a new sample has been added to the default dynamic.conf (dynamic_1010 for RAdmin 2.x, which uses MD5 hashes of NUL-padded passwords) (JimF, Solar) * GPU support under recent Mac OS X (magnum, others) - CUDA working, OpenCL partially working - see doc/BUGS for more detail * The first GPU (as opposed to possibly a CPU) is now found automatically when no specific OpenCL platform/device is requested (magnum) * Bugfixes for GPU formats: mscash-cuda, pwsafe-cuda, pwsafe-opencl (Lukas) * Bugfixes for GPU formats: raw-sha512-cuda, raw-sha512-opencl, xsha512-cuda, xsha512-opencl (myrice) * Speedup for phpass-opencl, mscash2-cuda (Lukas) * Speedup for mscash2-opencl (Sayantan, Solar) * Corrected detection of different salts in mscash-cuda, mscash2-cuda, mscash2-opencl (Solar) * Updated comments printed for some GPU formats (removed "unreliable" notices from formats that are now reliable, added "inefficient" notices to formats that exist primarily to support further development) (magnum, Solar) * hccap2john bugfix (this program was non-working in jumbo-6) (Solar) * pdf2john bugfix (this program was non-working in jumbo-6) (JimF) * keychain2john integrated into build (Solar) * Support for more varieties of PKZIP archives (JimF) * Better early rejection for RAR (huge speedup at -p archives) (magnum, Pavel) * RACF and VNC formats speedup (Knug Carl Gustf) * SIP, WoltLab Burning Board 3 formats speedup for non-OpenMP builds (Solar) * x86-64 SSE2+ interleave settings for LLVM and GCC 4.7+ (magnum) * Greater use of XOP in SHA-1 (now also in round 3) (Sayantan, Solar) * The --list option's supported set of parameters has been extended (use "--list=help" to find out what's available) (Frank, magnum) * \xNN escape sequence now works inside preprocessor ranges (magnum) * More test vectors for various formats, including based on KoreLogic's CMIYC 2012 challenges (JimF, others) * Wordlist parsing bugfixes (in particular with CR chars) (magnum, Solar, Guth) * Build failure fixes for many platforms/targets (magnum, Solar, others) * Many other bugs fixed, fewer new bugs introduced, some code changes made, some documentation revisions made (all) * doc/BUGS has been mostly rewritten to reflect the remaining issues (Solar) * Minor updates and fixes to bash completion (Frank) * Filter_Rot13 external mode sample (Frank) * Many updates to pass_gen.pl (JimF, magnum) * This changes overview has been compiled (Solar) Here are some new speeds on HD 7970 (stock clocks): $ ./john -te -fo=mscash2-opencl -pla=1 OpenCL platform 1: AMD Accelerated Parallel Processing, 2 device(s). Using device 0: Tahiti Optimal Work Group Size:256 Kernel Execution Speed (Higher is better):1.583098 Benchmarking: M$ Cache Hash 2 (DCC2) PBKDF2-HMAC-SHA-1 [OpenCL]... DONE Raw: 104025 c/s real, 103614 c/s virtual $ ./john -te -fo=phpass-opencl -pla=1 OpenCL platform 1: AMD Accelerated Parallel Processing, 2 device(s). Using device 0: Tahiti Benchmarking: phpass MD5 ($P$9 lengths 0 to 15) [OpenCL]... DONE Raw: 1714K c/s real, 36864K c/s virtual (Lukas already has phpass code faster than that - it's been posted publicly to john-dev in August - but this release is conservative, sort of a "stable jumbo", even though that's an oxymoron.) 2. There's a lot of talk lately about PHP applications and PHP proper often suffering from insufficient randomness, using PRNGs (often with small and/or predictable seeds and/or internal state) for purposes where cryptographically secure random numbers would be needed. Here's the start of the relevant thread on oss-security: http://www.openwall.com/lists/oss-security/2012/08/09/7 (click "thread-next" for a lot more of it). Here are some recent publications: https://www.usenix.org/conference/usenixsecurity12/i-forgot-your-password-randomness-attacks-against-php-applications http://blog.ptsecurity.com/2012/08/not-so-random-numbers-take-two.html In this context, I got curious of whether and why PHP's mt_rand() is really significantly more difficult to "crack" (find the seed given a series of "random" numbers) than an LCG PRNG (which was "crackable" in under a second on one CPU back in 1990s). Well, yes, it appears that mt_rand() is in fact hundreds of times "stronger", yet is "crackable" on one modern CPU chip in one minute (without use of precomputation yet). Here's a program I wrote: http://download.openwall.net/pub/projects/php_mt_seed/ Here's a sample run. First, generate a sample "random" number (using PHP 5.3.x in this case): $ php5 -r 'mt_srand(1234567890); echo mt_rand(), "\n";' 1328851649 Now build and run the cracker (php_mt_seed version 2.1 here): $ make gcc -Wall -march=native -O2 -fomit-frame-pointer -funroll-loops -fopenmp php_mt_seed.c -o php_mt_seed $ time ./php_mt_seed 1328851649 Found 0, trying 637534208 - 671088639, speed 63310249 seeds per second seed = 658126103 Found 1, trying 1207959552 - 1241513983, speed 63343447 seeds per second seed = 1234567890 Found 2, trying 4261412864 - 4294967295, speed 63347894 seeds per second Found 2 real 1m7.798s user 9m1.942s sys 0m0.008s In one minute of real time (on an FX-8120 CPU, using vectorized fused multiply-add instructions), it found the original seed, another seed that also produces the same mt_rand() output, and it searched the rest of the 32-bit seed space (not finding other matches in this case). Gifts implemented the same thing in OpenCL: https://github.com/Gifts/pyphp_rand_ocl https://github.com/Gifts/pyphp_rand_ocl/tree/SpeedyOCL His SpeedyOCL branch achieves similar performance (and even 10% better than mine in his test of both on a Core i5-2500) on CPUs (with Intel's OpenCL SDK) and several times better performance on GPUs. Finally, here's a far more generic cracker (but slower - 20 minutes on CPU?) by George Argyros: http://www.openwall.com/lists/oss-security/2012/09/20/8 https://github.com/GeorgeArgyros/Snowflake (I think it'd be possible to bring the time down to 1 minute if the generality is implemented by different means.) <obvious> Once the PRNG seed is known, further "random" numbers may be predicted reliably. Additionally, the seed itself might reveal information (depending on what was used as the seed). </obvious> 3. I will talk at Yandex's YaC 2012 conference (October 1st, Moscow, Russia) on future password hashing setups for Internet companies with millions of users and passwords. In a sense, this will be a continuation of my PHDays talk, with focus on specific challenges faced at and solutions affordable to this sort of companies. I'll mostly assume that the audience is readily familiar with the material I presented at PHDays: http://www.openwall.com/presentations/PHDays2012-Password-Security/ Here's the abstract for my upcoming YaC talk (in Russian): http://events.yandex.ru/talks/326/ I was already asked on Twitter whether I'd post English language slides online. The answer is yes, I intend to - after my talk, indeed. Attendance at YaC is free of charge; registration is open until September 28. Of interest to subscribers of this list may be the fact that among other speakers at YaC this year are 3 key developers of OpenVZ (two talks; one is on an unrelated topic, though). At Openwall, we're using OpenVZ as part of our Openwall GNU/*/Linux distro. 4. And this reminds me that I should abuse this opportunity to mention that I've recently setup a personal Twitter account @solardiz: http://twitter.com/solardiz I use it to post tweets that I'd find inappropriate for @Openwall, which you should be following too: http://twitter.com/Openwall I am also going to announce these things on john-users, for possible follow-ups. Besides, there's surprisingly little overlap between subscribers of the announce and john-users lists. 5. Finally, it just occurred to me that I never mentioned our participation in KoreLogic's Crack Me If You Can contest at DEFCON this summer in here, on the announce list (we did discuss it on john-users indeed). We had 21 active members on team john-users, and our team spirit was great! We ended up taking 2nd place. Here's our writeup, with links to many individual members' writeups: http://contest-2012.korelogic.com/team_john-users.html 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.