[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b34af1ea1eb3a929a0532a0c1449e3e@smtp.hushmail.com>
Date: Thu, 20 Sep 2012 14:11:10 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: 1.7.9-jumbo-7
On 2012-09-20 13:35, Solar Designer wrote:
> On Thu, Sep 20, 2012 at 11:46:28AM +0200, magnum wrote:
>> I tested this patch on OSX 10.8.1:
>>
>> macosx-x86-64 builds and runs fine, and CUDA does too.
>>
>> OpenCL builds fine, but a number of formats fail at run-time (bf,
>> mscash2, nt, rar, raw-sha512, sha512crypt, wpapsk and xsha512).
>
> bf-opencl may require smaller WORK_GROUP_SIZE in opencl_bf_std.h.
> Otherwise you're probably exceeding the available local memory size on
> your GPU.
I tried but even a WORK_GROUP_SIZE of 1 and a MULTIPLIER of 1 bugs out.
I have 48 KB local and 1 GB global but something else must be too small,
because if I run with CL_LOG_ERRORS=stderr, I do see "CL_OUT_OF_RESOURCES".
BTW the work group size should be auto-detected. I believe Claudio does
this properly.
> Here's my current BUGS:
...
> Even though wpapsk-cuda and wpapsk-opencl primarily use the GPU, they
> also do a (small, but not negligible) portion of the computation on CPU
> and thus they substantially benefit from OpenMP-enabled builds. We
> intend to reduce their use of CPU in a future version.
The above applies to rar too, although the actual speed is near the raw
speed in most cases.
> "Single crack" mode is relatively inefficient with GPU-enabled formats
> (and sometimes with OpenMP on CPU as well), because it might not be able
> to produce enough candidate passwords per target salt to fully utilize a
> GPU, as well as because its ordering of candidate passwords from most
> likely to least likely is lost when the format is only able to test a
> large number of passwords concurrently (before proceeding to doing the
> same for another salt). You may reasonably start with quick "single
> crack" mode runs on CPU (possibly without much use of OpenMP) and only
> after that proceed to using GPU-enabled formats (or with heavier use of
> OpenMP, beyond a few CPU cores), locking those runs to specific cracking
> modes other than "single crack".
BTW, RAR has a work-around for this problem: It switches to CPU unless
it is given enough of candidates. I opted not to do this for the office
opencl formats but maybe I should, given our future ripping of keywords
to GECOS.
> Some formats lack proper binary_hash() functions, resulting in duplicate
> hashes (if any) not being eliminated at loading and sometimes also in
> slower cracking (when the number of hashes per salt is large). When
On a side-note, is it even possible to make these formats use fake
"binaries" instead of fake "salts" for their non-hashes? I have tried to
picture this but I fail to sort it out in my head. The binary_hash()
could make a digest of the whole binary. The salts could actually be
used properly in some cases (RAR, for one).
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.
