[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b8ee214a40b48d9f2e750355f3a886dd@smtp.hushmail.com>
Date: Mon, 18 Jun 2012 09:47:37 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reduced binary size
On 2012-06-18 02:51, magnum wrote:
> I just committed reduced binary size for raw-md4/md5/sha1 and nt2. Saves
> 3 or 4 bytes per loaded hash (makes some difference for 135 million
> hashes, lol) and should help keeping good stuff in cache. It's not
> merged to bleeding yet - the get_source() gets a little trickier and I
> should get some sleep.
>
> It passes Test Suite - actually I would have committed a hideous bug in
> SHA-1 if it wasn't for TS.
This is now merged to bleeding but I will revert it, except for raw-md4
which doesn't use get_source().
Obviously, get_source() will not be safe if we use a reduced (32 bits)
binary. We might produce false positives, as we never really compare
with the full original binary. These false positives will be "reset"
(hashes will be regarded as remaining) on next run/resume of the hash,
as the john.pot hash will not match the ciphertext. But it's still not
acceptable. I see no way other than making these techniques mutually
exclusive, unless someone has a clever solution (theoretically,
get_source could re-read the original source from its file).
get_source() saves several tenths of byte per hash while reduced binary
just save a couple of bytes, so reduced binary has to go.
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.
