[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66d704e8e3faf77c3a932a59b57e96d5@smtp.hushmail.com>
Date: Mon, 18 Jun 2012 23:06:12 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reduced binary size
On 2012-06-18 20:44, jfoug wrote:
>> From: magnum [mailto:john.magnum@...hmail.com]
>
>>> 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.
>
> If the index was sent (meaning we are calling get_source for the 17th
> password), and this call comes after the crypt_all, then the format can use
> the completed hash, to re-create the binary hash value.
That would save us from looping through the crypt_key array but we still
can't know if it's a false positive (partial collision). I think this
might be a good thing for things like repairing crippled LinkedIn hashes
though. Otoh the loop for finding it was trivial.
BTW I'm still using the repairing variant of LI format despite its
shortcomings. I wonder how much we'd need to hack core to make it behave
better.
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.
