Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.