[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F2BB0A6.2050303@linuxasylum.net>
Date: Fri, 03 Feb 2012 11:02:14 +0100
From: Samuele Giovanni Tonon <samu@...uxasylum.net>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL vs Test Suite
On 02/03/12 01:20, magnum wrote:
> On 02/03/2012 12:46 AM, Samuele Giovanni Tonon wrote:
>> On 02/02/12 20:30, magnum wrote:
>>> 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
>
> Very simple really. CVS John want the salt to be aligned to ARCH_SIZE
> (for this salt size anyway) so we alloc it with MEM_ALIGN_WORD. But then
> you do not return &realcipher[0] but &realcipher[BINARY_SIZE] and
> BINARY_SIZE is 20. This makes it unaligned by 4 bytes. This is really
> John being too picky (as the format really does not rely on alignment)
> but I think it's a good thing and there are just a few formats that
> needed this kind of bodge. See
> http://www.openwall.com/lists/john-dev/2012/01/16/18. Anyway, what I do
> is just alloc 4 extra bytes and advance the pointer with 4 so
> &realcipher[BINARY_SIZE] is aligned :)
got it, many thanks :-)
>>> 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).
> ...
>> so basically i should be able to crack till PLAINTEXT_LENGTH and not
>> PLAINTEXT_LENGTH -1 , correct me if i'm wrong.
>
> Correct. BTW, in Jumbo we assume candidates are already truncated when
> passed to set_key() so do not waste any extra time on length checks
yes, the only legnth check needed is in the cl kernel since it doesn't
know anything about the password and i need to prepare the input pad.
> (until the day you add support for UTF-8 for Unicode formats like NT but
> that is another story). And this is also a reason you should never
> report a larger size than you actually can handle...
yep i understand; btw ssha should scale with no problem up to 64, about
UTF-8 and Unicode i just don't want to think about that until i'm 50 :-)
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.
