Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <990912b210ca6ffaadd146f6f2b863b3@smtp.hushmail.com>
Date: Mon, 26 Aug 2013 23:07:19 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Sayantan Weekly Report #11

On 26 Aug, 2013, at 20:34 , Sayantan Datta <std2048@...il.com> wrote:
> Accomplishment:
> - added support for other modes with existing mask mode for nt,md4,sha1 opencl.
> - optimized nt,md4,sha1 for large hashes.
> - fixed tons of segfault issues.
> 
> Priorites:
> - optimized mscash opencl and add support for other modes.
> - Also I want to introduce a change in format params which will include two new parameters *mask_context and num_internal_keys. I will post the patch for review before pushing it bleeding-mask and bleeding-jumbo.

FWIW your latest patches made it work on my MacBook w/ its tiny nvidia GT 650M (I'll have to use GWS environment variable though). Really decent figures for some types I think - but I have no idea how OclHashCat would perform if I booted Linux and tried it.

$ GWS=$((64*1024)) ../run/john test -form:nt-opencl -mask=?l?l?l?l?l?l?l
Device 1: GeForce GT 650M 
Local worksize (LWS) 64, Global worksize (GWS) 65536
Loaded 1 password hash (nt-opencl, NT [MD4 OpenCL (inefficient, development use only)])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:30 0g/s 390192p/s 267727Kc/s 267727KC/s aazyxjk..aazyxjk
Session completed

I did not expect 267Mc/s on this laptop! But I have verified it - it does crack things and it does seem to be a correct figure.

$ GWS=$((64*1024)) ../run/john test -form:raw-md4-opencl -mask=?l?l?l?l?l?l?l
Device 1: GeForce GT 650M 
Local worksize (LWS) 64, global worksize (GWS) 65536
Loaded 1 password hash (Raw-MD4-opencl [MD4 OpenCL (inefficient, development use only)])
Press 'q' or Ctrl-C to abort, almost any other key for status
Multiply the c/s rate with:676 to get the correct c/s rate
0g 0:00:00:32 0g/s 362126p/s 362126c/s 362126C/s aazyxjk..aazyxjk
Session completed
$ bc <<< 676*362126
244797176

$ GWS=$((128*1024)) ../run/john test -form:raw-md5-opencl -mask=?l?l?l?l?l?l?l
Device 1: GeForce GT 650M 
Local worksize (LWS) 64, global worksize (GWS) 65536
Loaded 1 password hash (Raw-MD5-opencl [MD5 OpenCL (inefficient, development use only)])
Press 'q' or Ctrl-C to abort, almost any other key for status
Using kernel md5_ccc...
0g 0:00:00:38 0g/s 309330p/s 211363Kc/s 211363KC/s aazyxjk..aazyxjk
Session completed

$ GWS=$((64*1024)) ../run/john test -form:raw-sha1-opencl -mask=?l?l?l?l?l?l?l
Device 1: GeForce GT 650M 
Local worksize (LWS) 64, Global worksize (GWS) 16384
Loaded 1 password hash (Raw-SHA1-opencl [SHA1 OpenCL (inefficient, development use only)])
Press 'q' or Ctrl-C to abort, almost any other key for status
c/s rate shown in status report is buggy. Multiply the p/s rate with:676 to get actual c/s rate.
0g 0:00:02:20 0g/s 84420p/s 57370Kc/s 57370KC/s aazzvpo..aazzvpo
Session completed
$ bc <<< 676*84420
57067920

57M for SHA1 is a bit disappointing - running wpa-psk I get 106M (sha1/s).

The p/s versus c/s figures are confusing but NT and MD5 now show correct c/s. Is a core change needed somewhere to get p/s right? I start to think so.

Just thinking out loud, I wonder how we want to [eventually] fix the status line candidate output. I think the current aazzvpo..aazzvpo should be either aazzvpo..zzzzvpo or a single **zzvpo. For some masks it's really confusing now:

$ GWS=$((64*1024)) ../run/john test -form:nt-opencl -mask=?d?d?d?d?d?d?d  
Device 1: GeForce GT 650M 
Local worksize (LWS) 64, Global worksize (GWS) 65536
Loaded 1 password hash (nt-opencl, NT [MD4 OpenCL (inefficient, development use only)])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:00 0g/s 11235p/s 11235Kc/s 11235KC/s 0000000..0000000
Session completed

The 0000000..0000000 looks like a bug but it's just cosmetical. Printing it as ******* would be less confusing but actually printing 0000000..9999999 would of course be the best... hmm but I think I would actually prefer ******* because it'd show how things are handled.

magnum

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.