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.