[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F240B31.8070302@linuxasylum.net>
Date: Sat, 28 Jan 2012 15:50:25 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL vs Test Suite
On 01/27/12 21:12, magnum wrote:
> On 01/27/2012 08:40 PM, Samuele Giovanni Tonon wrote:
>> On 01/27/12 00:46, magnum wrote:
>>> I did not notice some formats have a lower max size than SSE2
>>> ones. Hopefully, some of the formats are OK! But ssha-opencl is not :)
>>>
>> yes ssha-opencl is setted to have password up to 15 chars; this due to
>> to speed issue on opencl; however you can switch plaintext_length to
>> 32 and there shouldn't be problem .
>>
>> one question; on a general side, what is the perfect PLAINTEXT_LENGTH
>> value ? 32 is it good enough ?
>
> IMHO yes. On the other hand, how/why is it a bottleneck? If you support
> 55, but run a crack session with only short (eg. 8 characters)
> candidates, is it still a bottleneck? Most intrinsics formats are
> limited to 55 byte crypts (for eg. NT, that is just 27 characters)
> because beyond that you need to do another crypt call. Good or bad, it's
> a very logical limit.
this due to the buffer i send to the GPU that needs to be "prepared"
before in the init function :
buffer_keys =
clCreateBuffer(context[gpu_id], CL_MEM_READ_ONLY,
(SHA_BLOCK) * SSHA_NUM_KEYS, NULL, &ret_code);
with SHA_BLOCK that is PLAINTEXT_LENGTH (in fact i could merge
those two define in a single one ) .
bottleneck exist even if you use shorter password due to the fact i
"send" sha_block * ssha_num_keys through pci express .
this is a test with 16 as plaintext_length
./john -test -fo:ssha-opencl
OpenCL Platforms: 1
OpenCL Platform: <<<AMD Accelerated Parallel Processing>>> 2 device(s),
using device: <<<Cayman>>>
Max Group Work Size 256 Optimal Group work Size 64
Benchmarking: Netscape LDAP SSHA OPENCL [salted SHA-1]... DONE
Many salts: 57568K c/s real, 67494K c/s virtual
Only one salt: 42757K c/s real, 47869K c/s virtual
this is a test with 32
john -test -fo:ssha-opencl
OpenCL Platforms: 1
OpenCL Platform: <<<AMD Accelerated Parallel Processing>>> 2 device(s),
using device: <<<Cayman>>>
Max Group Work Size 256 Optimal Group work Size 64
Benchmarking: Netscape LDAP SSHA OPENCL [salted SHA-1]... DONE
Many salts: 42757K c/s real, 51811K c/s virtual
Only one salt: 30541K c/s real, 34568K c/s virtual
> If merely *supporting* longer is always slower and you can't work around
> it, I could live with even shorter than 32 - possibly even 16.
i can work a bit seeing if i can improve, this happens only on fast
algorithm like sha1.
cheers
Samuele
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.
