Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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