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.