[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 08 Jun 2012 09:11:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: rawSHA1_LI internals (was: JtR to process the LinkedIn hash dump)
On 06/08/2012 07:22 AM, Frank Dittrich wrote:
> The other solution is similar, but involves you new get_source.
> It should be trivial to restore the correct sha1 hex string, even if you
> loaded the one with '00000'.
> This could make the cracked LinkedIn hashes stored in john.pot valid for
> the normal raw-sha1 format.
> (Assuming that the '00000' don't cause false positives, but that should
> be a valid assumption.)
I had a similar thought. I think this is a cool idea. Could we do it
without hacking core? We need to do this:
1. Always load hashes (binaries) with first 20 bits cleared.
2. Always store complete hashes.
3. Always compare hashes without regarding first 20 bits.
#3 is easy when cracking (already done in cmp_*) but how about when
loading and comparing to john.pot entries? Could prepare() be used?
BTW Jim, I'm just now comparing rawSHA1_fmt_plug.c and
rawSHA1_LinkedIn_fmt_plug.c using meld. I notice cmp_all() is unchanged.
I must be missing something, how can this work? We should only look at
binary[1] but as far as I can see this is not the case. I know the code
works, but how!?
Also, I really think half of the self-tests should have the zeroed bits.
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.
