[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <76e76416573bfa9681705c7146c30655@smtp.hushmail.com>
Date: Mon, 18 Jun 2012 19:32:33 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reduced binary size
On 2012-06-18 17:59, jfoug wrote:
>> From: magnum [mailto:john.magnum@...hmail.com]
>>
>> 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).
>
> I am going to toss something out, not that I have thought this through, but
> to get discussion going. Would there be a way we could store the offset to
> the hash within the input file, and have get_source use that? I could see
> something like that being done on non-salted types. We do have a pointer
> 'free'. This pointer originally was used for the source. It has been
> repurposed to point to the actual salt. But for a non-salted format, could
> we steal this, yet again, and jam a file offset into it?
That's a thought but I agree with Frank this comes with caveats. After
giving all of this some thought I think we should settle for mutex:
Either we use get_source() and save a lot, or in cases where we simply
can't do that (like in sapB, where binary() can't be unambigously
reversed for performance reasons) we have the option to use reduced
binaries instead and save about half of that lot.
> One other 'way' to do this, is to pass in the index to get_source(). This
> method 'may' allow us to rebuild, AFTER the crypt_all has been run. There
> may be issues where this method is not ideal, and may not be 'good enough'
> for many formats.
Not sure what you mean.
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.
