Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Jun 2005 00:03:57 +0400
From: Solar Designer <>
Subject: Re: Dupes recognition based on internal representation of ciphertext?


It's a very interesting issue you've raised.  Sorry I didn't get
around to responding to you earlier.

On Sun, Jun 05, 2005 at 09:37:58PM +0200, Frank Dittrich wrote:
> It looks like the dupes recognition in cracker.c (crk_process_guess)
> is based on the internal representation of the ciphertext.


Arguably, the loader should be enhanced to also use internal
representations when it avoids loading dupes(*) for cracking and when
it displays cracked passwords.  I haven't tried doing it yet, but I
expect the latter change to resolve the problem you point out below.

(*) The current logic in JtR is to only load duplicate hashes when in
"single crack" or batch modes, and only when login names differ.

Alternatively, the split() method for affected hash types should be
enhanced to canonicalize the text representations.

> $ ./john --format=raw-md5 --wordlist=p h
> Loaded 3 password hashes with no different salts (Raw MD5 [raw-md5])
> abc              (3)
> abc              (2)
> abc              (1)
> guesses: 3  time: 0:00:00:00 100%  c/s: 5.55  trying: abc
> it looks like all passwords have been guessed.
> However, only one hash gets saved in john.pot:
> $ cat john.pot
> 900150983cD24fB0d6963F7d28E17f72:abc
> $ ./john --show h
> 3:abc
> 1 password cracked, 2 left
> Of course, for raw MD5 the problem can be avoided by just
> translating all hashes to lower case.

BTW, this is best done in split().

> But there might exist hash algorithms which use different external
> representations for the same hash.

Yes.  In fact, LM hashes, as implemented in the official JtR, are
affected by this (but non-all-uppercase LM hash strings are rare, so
this was never reported to me).

Thank you for the bug report!

> In this case, it's unfortunate that not all external representations
> get saved in john.pot.

Well, yes, but it won't be optimal to have multiple representations
stored in the file, yet not have yet another representation of the
same hash recognized by "john --show" without having to crack the hash

Meanwhile, you can use the trivial fix to cracker.c if you like: in
the log_guess() function call, remove the "dupe ? NULL : ".

Thanks again,

Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Was I helpful?  Please give your feedback here:

Powered by blists - more mailing lists

Your e-mail address:

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