[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP326C6F92B93B5BDADE1C04CFDC20@phx.gbl>
Date: Thu, 26 Jul 2012 10:50:27 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Aleksey's status report #13
On 07/26/2012 09:58 AM, Aleksey Cherepanov wrote:
> As of markov mode takes ranges in a parameter mjohn thinks about two
> ranges of markov mode as about two different attacks at this time.
> It is a problem to fix during adding support for attack options.
I think that's absolutely OK.
Who defines such separate markov attacks has to make sure they don't
overlap. May be it even is useful to fist define just a few attachs with
small ranges.
If this doesn't work well, try other attacks first, if it works well,
try other ranges before switching to new attack types...
>> How did you decide which parameters are "cosmetic"?
>
> Quickly...
>
>> IMO any parameter which changes the "output" (generated candidates) is
>> not cosmetic.
>
> I tried to follow this rule.
>
>> At least --length will result in different candidates being generated.
>> Not sure it makes sense to use this parameter.
>
> It is a bug in mjohn. Fixed. --length is not a cosmetic option more.
OK
>> 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 guess you could not restore attack so, could you?
OK, so al long as the attack is restored on the same client, we
shouldn't have problems.
If a user changes the dupes suppression, he usually knows (or should
know) about the impact.
>> 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.
>
> I'll separate percentages from attack. So percentages will be a
> property of session (each attack have different sessions: currently
> sessions differ by hash type, then partial sessions should be
> supported, i.e. percentages of markov).
I think there is no need to change anything related to markov mode right
now.
> To split I could use --node functionality: select quite small part of
> attack (start point) and track its end and real progress (end point;
> so to restore it and finish we do not make new part of attack that
> covers remaining part, instead we just redo that whole part).
Yes. But don't make it too small, otherwise loading the hashes and
communication between client and server will take a significant part of
the total run time. Keep this overhead at a reasonable level.
(That means, for fast, saltless hashes, we shouldn't split an attack in
too many parts.)
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.
