[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF5WNqnAxs4xMyz_jj73ycx57_tMBNLK29NU=-8vdcq6iDvb8Q@mail.gmail.com>
Date: Fri, 14 May 2021 21:00:51 -0700
From: David Sontheimer <david.sontheimer@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking stats: p/s, c/s and C/s. Hashing cost factors.
Alexander,
I should add the high-level goal:
I'd like to test my password generation heuristics as you are testing
your .chr files' candidate generation - using the same number of
max-candidates across trials, and recording the percentage of passwords
cracked in each trial. This is preferable to comparing heuristics by total
time to crack all passwords.
Further, I'd like to calculate the average number of candidates required to
successfully guess a hash. A binary search wrapper was discussed, but
StatusShowCandidates appears to be perfect (and more efficient).
Using StatusShowCandidates = Y shows the candidate count of a successful
candidate for a single fork, not all candidates across all forks, correct?
If so, then the best use of my hardware appears to be running each trial on
a single fork, and running many trials in parallel. Unique, session-named
log files will be required for exact candidate counts (as opposed to the
multiple of batch size printed to stdout) and to differentiate the results
between trials.
-David
On Fri, May 14, 2021 at 8:46 PM David Sontheimer <david.sontheimer@...il.com>
wrote:
> Alexander,
>
> (I wouldn't call it a range. It is a subset of the total, but calling
>> it a range could be misleading.)
>>
>
>
>> For generated candidate passwords, hashes are computed for each target
>> salt (that is, for each salt ever seen among the loaded hashes), and are
>> then compared against loaded hashes that have that salt.
>>
>> You might find slides 7 to 10 in this presentation helpful:
>>
>>
>> https://www.openwall.com/presentations/BSidesLjubljana2017-Yescrypt-Large-scale-Password-Hashing/
>>
>
> This is helpful - thank you.
>
> When parallelized, would optimal be that the set s0 for fork 0 contains
> the most-likely candidate, the set s1 for fork 1 contains the second
> most-likely candidate, ... , set sN for fork N contains the Nth most-likely
> candidate?
>
> As you put it in slide 10, "groups of more likely passwords first."
>
> There are these options:
>>
>> --max-candidates=[-]N Gracefully exit after this many candidates
>> tried.
>> (if negative, reset count on each crack)
>> --max-run-time=[-]N Gracefully exit after this many seconds (if
>> negative,
>> reset timer on each crack)
>>
>
> Excellent - much appreciated.
>
> Now, with a fixed runtime/fixed candidates to test, I'd like to run
> separate cracking sessions in parallel. Where do I find the named log file
> based on session name, as described in:
>
> https://github.com/openwall/john/blob/bleeding-jumbo/doc/OPTIONS?
>
> It should be in the same directory as ${JOHN}/john.log, correct?
>
> --session=NAME give a new session the NAME
>> This option can only be used when starting a new cracking session and
>> its purpose is to give the new session a name (to which John will
>> append the ".rec" suffix to form the session file name). This is
>> useful for running multiple instances of John in parallel or to be
>> able to later recover a session other than the last one you interrupt.
>> john.log file will also be named NAME.log (whatever 'NAME' is), so
>> that any logging of the session work will end up in this file.
>
>
> Here is my command (for example, SESSION =
> "experiment_2021-05-12_16:13:06.153197"):
>
> ${JOHN}/john --session=${SESSION} --fork=1
>> --pot=${EXPERIMENTS}/${SESSION}/cracked_len_10.pot --incremental=Digits
>> --min-len=10 --max-len=10 --max-candidates=10000000
>> ${EXPERIMENTS}/${SESSION}/pwdfile_sha1_crypt_10.txt 2>
>> ${EXPERIMENTS}/${SESSION}/cracked.err 1>
>> ${EXPERIMENTS}/${SESSION}_cracked_len_10.out
>>
>
> Further, how does --session interact with LogFileProtect in john.conf?
>
> I would expect "LogFileProtect = Named" to not allow named sessions to
> write to john.log, nor to write to other named session logs, yet they would
> write to their own session's NAME.log.
>
> Instead, when uniquely naming sessions and with "LogFileProtect = Named" I
> do not see session-named logs created, and no new data is added to john.log
> (the latter which is expected).
>
> I have looked through both doc/OPTIONS and john.conf for a separate,
> independent variable to enable session-named logs, but no luck.
>
> -David
>
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.
