[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 03 Feb 2012 00:46:13 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL vs Test Suite
On 02/02/12 20:30, magnum wrote:
> On 01/27/2012 08:40 PM, Samuele Giovanni Tonon wrote:
>> On 01/27/12 00:46, magnum wrote:
>>> On 01/27/2012 12:29 AM, jfoug wrote:
>>>> Many of these 'may not' be problems. What they often are, is the format has
>>>> a limitation of length of password that is 'able' to be tried.
>>>>
>>>> That is fully acceptable. If the format only handles words up to 18 bytes,
>>>> and there are 50 of them that are 19 to 32 in there, then expect them to
>>>> fail.
>>>
>>> True, 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 .
>
> The ssha issue (total fail in TS) was my bad, I used the wrong test file
> (though the CPU format *can* crack the one I used before!). Here is a
> new jtrts.dat (last 5 lines changed) with this corrected as well as
> expected cracks corrected for max lengths. Also, I spotted a couple of
> "problems":
>
> 1. The new aligment tests in CVS john (or bleeding-jumbo) makes ssha
> sometimes fail self-test on 64-bit. There is no real problem, but the
> enclosed patch for get_salt() gets rid of this.
thanks, i'm still trying to figure out the magic you did, but somehow
i'll look in to it
>
> 2. ssha has a PLAINTEXT_SIZE of 16 but only copied a maximum of 15 (due
> to strnzcpy reserving the last one for a null). The enclosed patch make
> it pass Test Suite with length 16 (and might be faster too). The
> assumptions is a null byte is not really needed (and it doesn't seem to be).
this is a question it's bothering me: alain on nt-opencl used
PLAINTEXT_LENGTH and then created all buffers with PLAINTEXT_LENGTH + 1 .
i'm using PLAINTEXT_LENGTH and on the .cl code you can see this:
for(i = 0; i < data_info[0] && ((uchar) plain_key[msg_pad + i]) != 0x0 ;
i++){
(data_info[0] contains PLAINTEXT_LENGTH value and plain_key[msg_pad] is
the address of the plaintext i'm going to cipher )
on the c side i switched from strncpy to memcpy so i forget about '\0'
memcpy(&(inbuffer[index*PLAINTEXT_LENGTH]), key, PLAINTEXT_LENGTH);
so basically i should be able to crack till PLAINTEXT_LENGTH and not
PLAINTEXT_LENGTH -1 , correct me if i'm wrong.
Plus memcpy is faster than strcpy .
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.
