[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130513211722.GB19368@openwall.com>
Date: Tue, 14 May 2013 01:17:22 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Incremental mode in 1.7.9.14
On Mon, May 13, 2013 at 10:28:49PM +0200, magnum wrote:
> Like most everyone else, I'm not fully understanding Incremental. So, would any training word *starting* with 'X' increase the chance of producing the complete candidate "X", or are only actual training words being exactly "X" counted?
Neither answer fully matches the reality. There's some separation
between the cracking order[], which is about character indices rather
than actual characters, and the sorted lists of characters. There's no
1-to-1 mapping from indices to actual characters since it varies by the
length and by the preceding 1 or 2 characters (OK, for length 1 this is
simpler). Also, the expand() logic, when it comes into play, may in
fact make a character such as 'X' appear closer to the start of an
expanded sorted string even if that character never appeared for the
same password length. Currently, when expand() takes data from another
length (a last resort fallback), it only does so via allchars, so info
such as where in that other length's passwords this character appeared
(e.g. at the start or not) is not used - this is one of the things I
meant when I mentioned that the expand() logic needs to be improved.
> I need to do more and longer tests to eliminate noise, and analyze the actual results to evaluate the exact differences... But here are quick results from 60s of attacking a test set of some 740,000 descrypt hashes unrelated to rockyou, with incremental trained from rockyou:
>
> 1e-3: 18279 guesses
> 0.01: 18328
> 0.1: 18342
> 0.5: 18316
> 0.9: 18333
> 1.0: 18326
Thanks! You could also test on fast and saltless hashes, which would
serve to simulate a longer run against descrypt (or slower).
And, where's the info on how this changed the position of rare one-char
passwords in the candidates stream? You should be looking at this as
well since making sure those trivial passwords will get cracked early on
was one of your goals.
Do you also have numbers for similar tests of 1.7.9's incremental?
> The result from using "1 / powi(10, length)" instead of a fixed number is 18367. So in this micro-test, it wins - and the 1e-3 is worst of all. But again, this is not very solid data and differences are small anyway.
This is interesting. Yes, need more and longer tests. This also gives
us two parameters to tune: the "1" and "10" in "1 / powi(10, length)".
> Maybe I should run -wo:rockyou before doing the tests, to filter the worst passwords from the counts.
Yes, we should consider the results of such tests too.
Thanks,
Alexander
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.
