[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Feb 2012 09:28:39 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL vs Test Suite
On 02/02/12 05:04, Solar Designer wrote:
> On Sat, Jan 28, 2012 at 03:50:25PM +0100, Samuele Giovanni Tonon wrote:
>> 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);
>
> Do you gain much by keeping this fixed size? Maybe adapt the block size
> to the maximum password length actually seen in the current block (which
> may vary from block to block)? That way, the GPU can start processing
> the candidate passwords in parallel right away (without having to scan
> the buffer sequentially first, like it would with a more advanced
> encoding scheme), yet the transfer size is reduced and the maximum
> supported password length is increased.
i don't think that would be possible due to the nature of opencl
architecture, we could end spending more time to createbuffer,
setkernelarguments, and writebuffer than by doing at fixed size.
this problem rise also when you just do a wordlist attack with a
dictionary of few words (for example 1000 ) while ssha_num_keys is
setted up to 1024 * 2048.
I'm doing some test for avoid the second case or, at least let the user
decide which ssha_num_keys is best for him, i hope to send the patches soon
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.
