[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 19 Dec 2005 02:45:20 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Dupes recognition based on internal representation of ciphertext?
> Solar Designer wrote,
> >The new rules for JtR patches implementing hashes with case-insensitive
> >encodings are as follows:
[...]
On Mon, Dec 19, 2005 at 12:03:37AM +0100, Frank Dittrich wrote:
> Different external representations for the same hash
> are not necessarily a matter of upper vs. lower case.
Indeed, and this is the primary reason I've called the current solution
"somewhat limited".
Unfortunately, a more generic solution which would achieve at least the
same functionality would not fit into the programming interfaces in
current JtR. In particular, there are two limitations in the way
binary() is defined:
1. It is meant to perform as much pre-processing as is possible (in
order to simplify actual cracking).
2. It may return partial hashes (in order to save memory and use caches
more optimally).
If I were to misuse binary() for matching hashes on "john --show", this
would run unnecessarily slow for some hash types (undoing DES FP, etc.)
and, more importantly, it would produce false positives (with no way to
filter them out since cmp_exact() only works on just-computed hashes).
So I've implemented whatever was reasonable to implement shortly before
making a "stable" release. This should be good enough for the hashes
currently supported by John, as well as for most if not all of the
contributed patches.
Yes, it would not catch invalid DES crypt(3) salts mapping to the same
12-bit (or 24-bit) values (although John would properly recognize that
at load), potentially resulting in the misbehavior you've illustrated in
your very first posting in this thread. That is, if such hashes of the
same plaintext password and with matching salt values but differing salt
encodings would be loaded for cracking simultaneously and would get
cracked, only one of the encodings would be recorded in john.pot, but
"john --show" and subsequent cracking runs would not recognize the other
encodings as already cracked. That's not nice indeed, but it's pure
theory. I have yet to hear of it happening in practice.
If you're aware of any other specific examples where the current
solution is insufficient, please let me know.
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
