[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 4 Jul 2015 22:17:21 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: more robustness
Hi Alexander,
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. What I should do is only add the incorrect passwords.
Mutate the original correct password, such as remove chars or add one
char by 1, and the expected result should be failed. Does the incorrect
passwords is to avoid false positives?
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.
Thanks,
Kai
Content of type "text/html" skipped
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.
