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.