[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120920201040.GA31967@openwall.com>
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.
