Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  news  community  lists  wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
Password Recovery Resources on the Net
[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Fri, 13 Jun 2008 18:16:41 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: raw-md5 module improvement

On Fri, Jun 13, 2008 at 03:48:28PM +0200, Bucsay Bal?zs wrote:
> I dont understand this, how can i make fake hashes? Whats the difference 
> between the fake and the real-world samples?

I thought that you could have generated strings of 32 hex characters
other than by computing MD5 hashes of something.  Depending on how you
generate those, you might or might not cause an excessive collision rate
in JtR's hash tables that are used to speedup comparisons.  But this
turned out to not be the case:

> When i increase the hash count, the c/s value is growing, but if i reach 
> the ~1500hash dream-line it gets to decreasing, it is the opposit of 
> your writing, ot just i dont understand this. So how is this working? :)

OK, I had a closer look at your patch - and the cause of this slowdown
is right there.  You're using the fmt_default_binary_hash and
fmt_default_get_hash dummy functions instead of real ones, specific to
your "format".  This means that JtR is not using hash tables for real at
all, making comparisons of computed hashes against those loaded for
cracking very slow when you load a lot of hashes.  You need to fix that.

Oh, and thanks for starting to work on the wiki content. :-)

Alexander

-- 
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux