Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Sep 2012 10:35:21 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Cc: Vladimir Vorontsov <vladimir.vorontsov@...ec.ru>
Subject: Re: salted raw MD5 on GPU

On Sun, Aug 19, 2012 at 12:00:57PM +0400, Solar Designer wrote:
> On Sun, Aug 19, 2012 at 03:46:06PM +0800, myrice wrote:
> > https://github.com/qqldd/myrice-JtR/tree/PG-test
> > 
> > Please checkout to PG-test branch after clone
> 
> Vladimir - please note that this PG-test tree contains plenty of formats
> that are broken by the formats interface change.  There are compile-time
> warnings for them.  These are to be ignored; that's how myrice
> experiments with this stuff currently.  You only need to be testing this
> one format:
> 
> > Example:
> > ../run/john -te=1  -fo=salt-md5-opencl -pla=1 -dev=0

I've just tested that this format works.  I started with:

git clone git://github.com/qqldd/myrice-JtR -b PG-test PG-test

Then applied the patch from:

http://www.openwall.com/lists/john-dev/2012/08/17/20

(c/s rate reporting fix, some optimizations), which myrice somehow did
not merge.

Then I built with "make linux-x86-64-opencl -j8" (which gave lots of
warnings for formats not updated to the new interface, as expected).

I took Vladimir's sample hash from his john-users posting:

http://www.openwall.com/lists/john-users/2012/08/12/1

"Example hashes:
4a68966aa97b5b273ccfef8c7350fa44:12345678 - password"

and put it in a file as follows:

$ cat pw
$MD5p$12345678$4a68966aa97b5b273ccfef8c7350fa44

Then I ran:

$ ./john pw -form=salt-md5-opencl -i=alpha -pla=1
OpenCL platform 1: AMD Accelerated Parallel Processing, 2 device(s).
Using device 0: Tahiti
Local work size (LWS) 128, Global work size (GWS) 65536
Loaded 1 password hash (Salted MD5 [OpenCL])
end self test
matched count: 1
password         (?)
guesses: 1  time: 0:00:00:01 DONE (Thu Sep  6 10:05:37 2012)  c/s: 1082M  trying: password - pudigt
Use the "--show" option to display all of the cracked passwords reliably

"-i=alpha" was producing various lowercase strings of lengths 1 to 8,
and the hard-coded charset and loops in md5_kernel.cl were appending two
chars from [a-zA-Z] to that (so strings being tested were of up to 10
characters long).  Eventually (after about 1 second), this cracked
"password" (of which "passwo" was tried by incremental mode and "rd" by
the loops in md5_kernel.cl).  The average speed was just over a billion
of candidate passwords per second.  Another test, letting this use the
full printable US-ASCII (95 characters) for the first portion (the last
two characters are still from [a-zA-Z] only):

$ ./john pw -form=salt-md5-opencl -i -pla=1
OpenCL platform 1: AMD Accelerated Parallel Processing, 2 device(s).
Using device 0: Tahiti
Local work size (LWS) 128, Global work size (GWS) 65536
Loaded 1 password hash (Salted MD5 [OpenCL])
end self test
guesses: 0  time: 0:00:00:05 0.00%  c/s: 1619M  trying: alymat - drap07
guesses: 0  time: 0:00:00:13 0.00%  c/s: 1897M  trying: d0de! - jun9g
matched count: 1
password         (?)
guesses: 1  time: 0:00:00:24 DONE (Thu Sep  6 10:09:57 2012)  c/s: 1994M  trying: password - r1l25b
Use the "--show" option to display all of the cracked passwords reliably

The speed has improved to almost 2 billion (there's less overhead in a
longer-running session), but the duration increased to 24 seconds (since
this was a less focused attack and more candidate passwords were tested).

Obviously, a wordlist would crack "password" instantly, but in this case
our format is weird, so it'd require "passwo" in a wordlist (or we'd
need a wordlist rule deleting the last two chars).  In fact, we seem to
have such a rule somewhere in the "jumbo" ruleset:

$ ./john pw -form=salt-md5-opencl -pla=1 -w=password.lst -ru=jumbo
OpenCL platform 1: AMD Accelerated Parallel Processing, 2 device(s).
Using device 0: Tahiti
Local work size (LWS) 64, Global work size (GWS) 65536
Loaded 1 password hash (Salted MD5 [OpenCL])
end self test
matched count: 4
guesses: 0  time: 0:00:00:03 2.76% (ETA: Thu Sep  6 10:14:20 2012)  c/s: 995084K  trying: rciaga - Janie
matched count: 1
password         (?)
guesses: 1  time: 0:00:00:10 DONE (Thu Sep  6 10:12:42 2012)  c/s: 1104M  trying: password - trevop

(I am puzzled by the "matched count: 4" early on, though.  Perhaps it
indicates a bug.)

Overall, this works, but is a dirty hack.  Changing the charset for the
last two positions requires editing alpha_set and ALPHA_SET_SIZE in
md5_kernel.cl, and the "*pcount *=" line in opencl_rawmd5_fmt.c and
opencl_saltmd5_fmt.c for proper c/s rate reporting.

...Oops, I forgot to correct it in the latter file in the tests above.
My patch only corrected it in opencl_rawmd5_fmt.c, but then myrice based
opencl_saltmd5_fmt.c on an older revision of that file, without that
correction.  So the c/s rates above need to be multiplied by
52*52/(53*53) = 0.96262.  That is, they're about 4% lower than reported.

Also, the salts are specified as-is, not hex-encoded, so some values
can't be specified.  (Easy to fix in opencl_saltmd5_fmt.c.)

opencl_rawmd5_fmt.c and opencl_saltmd5_fmt.c declare PLAINTEXT_LENGTH 31,
but my patch mentioned above actually limits the length of salt+password
combined to 32.  When this is a problem, it can easily be avoided (with
very minimal performance loss) by undoing the change to GET(i) in
md5_kernel.cl:

#define GET(i) (((i) < 8) ? key[(i)] : 0)

The check for "(i) < 8" may be removed (using key[(i)] unconditionally)
or adjusted (to increase/decrease the length limit).

Indeed, this code is still very far from optimal, but it does appear to
deliver speeds somewhat better than what Vladimir mentioned he was
getting with other tools.  Indeed, a future oclHashcat-plus release with
support for longer passwords will be a lot faster (actually optimized).

The above tests were on HD 7970.  I also tested on GTX 570, getting
about 1.1 billion passwords/second.  I wouldn't be surprised if this
shows worse speeds on Vladimir's 6990.  Samuele reported that an older
revision of md5_kernel.cl resulted in register spills on his 6970, and I
don't know if newer code avoids this or not (we did not deliberately try
to fix that problem yet - we were just experimenting with interfaces).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ