[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa8188fa65a749ede502d9ca3b5e7e5e@smtp.hushmail.com>
Date: Wed, 4 Sep 2013 00:03:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: mask mode bug (was: Sayantan's Weekly Report #12)
On 3 Sep, 2013, at 17:14 , magnum <john.magnum@...hmail.com> wrote:
> On 3 Sep, 2013, at 3:49 , Sayantan Datta <std2048@...il.com> wrote:
>> Priorities:
>> - Find more bugs and try to fix them.
>
> I think I found a main reason for segfaults. I only looked at raw-md5 but it might be in all/some of the others too:
>
> When you allocate pinned_partial_hashes and map partial_hashes, you allocate as "4 * kpc" (where kpc is synonym with GWS) while I believe it's supposed to be "multiplier * 4 * kpc" or perhaps rather "loaded_count * 4". I haven't fully digested the new code so I'm not sure which but it's definitely allocated too small now. This is easily triggered when using a low GWS and a high number of loaded hashes.
The enclosed patch seems to do the trick. I see another problem too: With 8-bit masks, eg. [\x20-\xff] (you need to escape or quote the backslashes in the shell unless adding it as ?A in rpp.c), it cracks hashes but you get false result from get_key (the worst bug next to false negatives!). The first character is garbage. Possibly a signed char problem? It works fine with CPU formats.
Also, I really dislike that you pin LWS to 64 in mask mode but maybe that's hard to work around.
Am I interfering with GSoC now? Just tell me to shut up :) It's so cool doing 250 Mp/s on a laptop, I can't stop myself.
magnum
Download attachment "mask_bug.patch" of type "application/octet-stream" (1681 bytes)
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.
