[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150704163455.GA23439@openwall.com>
Date: Sat, 4 Jul 2015 19:34:55 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: more robustness
Hi Kai,
On Sat, Jul 04, 2015 at 10:17:21PM +0800, Kai Zhao wrote:
> I want to discuss the idea of --test-full.
>
> > 1. JtR builtin extensive self-tests and/or formats fuzzer. Right now,
> > --test performs only very basic testing, hashing one password at a time
> > (albeit in different key indices). It is not uncommon for a format
> > being developed to pass self-test, yet fail to crack some passwords when
> > tested for real on a password hash file and a wordlist.
>
> > The extensive test should mimic actual cracking (testing groups of mixed
> > correct and incorrect passwords at once) and perhaps also combine it
> > with benchmarking. Right now, our --test starts with a quick self-test
> > and then proceeds with a benchmark, which are separate stages; with an
> > extensive self-test that mimics actual cracking, the self-test and
> > benchmark should be one and the same stage.
>
> Currently --test has already mimic actual cracking except it only contains
> correct passwords.
No, that's not the only aspect in which it differs from actual cracking.
As I wrote above, "--test performs only very basic testing, hashing one
password at a time (albeit in different key indices)".
So when max_keys_per_crypt is higher than 1, and it usually is, the
current self-test would only test one key at a time anyway. This means
that computation for other key indices is left untested. This is
mitigated by testing multiple key indices like that:
/* 0 1 2 3 4 6 9 13 19 28 42 63 94 141 211 316 474 711 1066 ... */
if (index >= 2 && max > ntests)
index += index >> 1;
else
index++;
but as you can see this does not result in an exhaustive set of indices,
and it is very wasteful (e.g., 712 passwords are hashed, most of them
uninitialized, to test only one index 711).
> What I should do is only add the incorrect passwords.
No, not only that.
> Mutate the original correct password, such as remove chars or add one
> char by 1, and the expected result should be failed.
That's fine.
> Does the incorrect passwords is to avoid false positives?
Do you mean whether testing with incorrect passwords is for detecting
false positives? Yes, and also to combine testing and benchmarking.
In actual cracking, the passwords being tested will be incorrect most of
the time, so you shouldn't have too high a ratio of correct passwords in
the combined test and benchmark phase (e.g., use 1:999). But you may
use a much higher ratio (like 1:1) in a pre-benchmark extensive test.
> Currently --test starts with a quick self-test to make sure the format works
> right and then proceeds with a benchmark. The benchmark only runs
> set_salt(), crypt_all() and cmp_all() functions. If we combine self-test and
> benchmark, does it means that we should keep self-test until timeout.
Yes, but see above: the combined test and benchmark may be a second
phase, after having completed an extensive test.
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.
