[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120710073025.GA30348@debian>
Date: Tue, 10 Jul 2012 11:30:25 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Aleksey's status report #11
On Wed, Jul 04, 2012 at 10:10:30PM +0200, Frank Dittrich wrote:
> On 07/04/2012 05:26 PM, Aleksey Cherepanov wrote:
> > That is my primary priority. Though it will be a bare bone thing.
> >
> > - Try to fix request tracker to get reasonable speed
> >
> >> - Look into other possible collaboration server side tool
> >> - Compare them by speed
> >
> > - Apply Frank's suggestions from status report #10
> >
> >> - Fix markup on the wiki page
> >
> >> - Research possible statistics and their importance
>
> Can you elaborate a little more what statistics you have in mind?
> (If it had already been discussed, just a pointer to a previous thread
> would be nice.)
One thing is efficiency: ratio of cracked passwords to count of
candidates. This could be real: by fact .pot length divided to john
--stdout ... | wc -l (currently I use new pot for each attack and
(plan to) filter cracked hashes out from file to crack). But this has
problems: if attacks overlap efficiency is low while attack could be
good in general, it could affect our decisions to proceed attack or
not badly.
On the other hand we could calculate absolute efficiency: like there
were not other attacks, i.e. ratio of totally cracked passwords found
among candidates to candidates count. This does not take overlaps into
account but it could be used to estimate overall efficiency of attack
based on already cracked passwords. It is rough but faster than
running 5% of real attack (though I doubt that makes any sense).
Also it could be nice to calculate overlap between keyspaces. Probably
it will be slow for big amount of attacks. Though it could be worth or
it is possible to do it in manual mode: calculate overlap only on
demand, for instance for attacks that seems to be close.
To track candidates lists on the server is not acceptable (as we
talked before). But their regenerating on clients would multiply work
several times. Though it is common to have spare hardware during
contest.
Talking about overlaps slow hashes will benefit from taking a
complement. So we avoid overlap mangling candidates lists: in our list
we avoid all candidates from other list(s).
Above I said about static efficiency. It does not respect that
cracking speed decreases. During CMIYC 2011 some members used time
since last crack: for instance if there were no cracks during last
minute then attack is too slow and should be replaced by new one. I
think it is a low precision way to estimate current attack efficiency.
Also I have some uncertain thoughts that it would be nice to
distinguish finite attack and infinite attack (or just with very big
keyspace): for finite attacks (like wordlist attacks) static
efficiency estimation is reasonable, while most of infinite attacks
(like incremental mode) should be estimated dynamically respecting
that most of cracks would be in the first time. Though incremental
mode could be enough small to be considered finite.
Do you know other useful properties of attacks?
Regards,
Aleksey Cherepanov
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.
