[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ead73a5587fa17bc7e2145250310899e@smtp.hushmail.com>
Date: Fri, 03 Feb 2012 01:20:09 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL vs Test Suite
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 :)
>> 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
(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...
> Plus memcpy is faster than strcpy .
Yes but in case you need buffer cleaning at destination, strncpy might
not be a bad idea sometimes.
magnum
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.
