Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ