Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 25 Feb 2012 02:14: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.

this sentence has been bothering me for a while.
due to the nature of opencl to hash in parallel, i have to decide before
which will be the max block (in this code SHA_BLOCK, now it's called
PLAINTEXT_LENGTH) .

so set_key will simply memcpy:

memcpy(&(buffer_keys[index*PLAINTEXT_LENGTH]), key, PLAINTEXT_LENGTH);

however if the max password i'm hashing is shorter than plaintext_lenght
due to the fixed transfer rate it will take some time.

the only way i can think to do a fixed  buffer_keys, but enqueue only
the right amount of passwords is to add an int (or char) array as
argument to the kernel, in that array there will be the length of the
password.
In that way i'm adding more data to transfer, but in the hope that
buffer_keys will be less than (sha_block*ssha_num_keys) bytes.
this means also changing set_key by adding a pointer to the last char
of previous password .

I can't think of other ways .

Cheers
Samuele

Powered by blists - more mailing lists

Your e-mail address:

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