Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF5WNqmMz8oXwuN7TVS7w5TTHSBX0QCRi-tGMmPTCrAd13_VqQ@mail.gmail.com>
Date: Fri, 14 May 2021 20:46:28 -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 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.