[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP312B3860AFBB29A9FEEE67FFDC30@phx.gbl>
Date: Wed, 25 Jul 2012 23:56:43 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's status report #13
On 07/25/2012 09:52 PM, Aleksey Cherepanov wrote:
> I missed two previous status reports. So this one covers two weeks. I
> am sorry.
>
> During these weeks I rewrote file management system to use scp and to
> be extensible. Currently it makes clients to download only files that
> are needed for some attack (not all files available like before).
> Possible improvement and extensions are already described. Also it
> could useful to think about what to do we are offline: use old files
> that we already have or give up and abort?
Depending on how many clients we have, we could just let each client run
an independent part of a markov attack against a particular hash file.
(This can even be done without using MJohn.)
In markov mode, the probability of password candidates range from
minimal possible markov level to the maximum markov level specified,
so each small part of a markov attack will have a more or less similar
distribution of very likely passwords and less likely passwords (up to
maximum markov level.
We just need to decide if we want to use the default stats file, some
other stats file generated from (a subset of) the rockyou.txt or some
other file, or if we want to wait for enough passwords to be cracked
during the contest...
> I got (near) working restore functionality: user could start attack by
> name. Problems here: I exclude cosmetic options (at this time:
> dupe-suppression save-memory mem-file-size crack-status mkpc length
> fix-state-delay) from attack (so they are not in 'parameters' file on
> the server)
How did you decide which parameters are "cosmetic"?
IMO any parameter which changes the "output" (generated candidates) is
not cosmetic.
At least --length will result in different candidates being generated.
Not sure it makes sense to use this parameter.
Also, --dupes-suppression is not really "cosmetic".
If you start with dupes suppression switched off, and restore with dupes
suppression switvhed on, you'll miss come words.
> I got a question: could I restore a session with other (reduced) hash
> file?
Yes, this is possible.
If you used --salts=N or --salts=-N, you'll continue the attack on a
different subset or the remaining hashes, though.
> It seems there are many actions I would like to perform that are tight
> to ability to start attack from some point, not the begin. Something
> like percentages for markov mode.
Using percentages for markov mode, you really define separate,
individual attacks.
Although it might make sense to finally cover the complete range, and
not cover some parts twice, other parts not.
> Adding an ability to get a status in
> percentages I'd be able to do a high-level restoration of attack. Also
> it would provide an ability to split an attack into pieces.
Please don't try to split attacks by manipulating .rec files.
At least not for not. (The few exceptions where it might be acceptable
to clone and adjust .rec files can be covered later.)
I need to stop now, and will probalby comment on other parts of your
status report tomorrow.
Frank
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.
