[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANWtx03x4PY0fF5s=17FCY-mQU0Pjb3QZNoV6cwXkVhg3n9NfA@mail.gmail.com>
Date: Thu, 14 Jun 2012 10:17:17 -0400
From: Rich Rumble <richrumble@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: notes on sharding the incremental search space
On Thu, Jun 14, 2012 at 8:49 AM, Tavis Ormandy <taviso@...xchg8b.com> wrote:
> Someone asked a similar question here, but I think they abandoned the idea:
>
> http://www.openwall.com/lists/john-users/2011/06/29/3
I just don't program, but I do try to "hack" in other ways, and .rec
points would have been the way a non-programmer like me would do it :)
> This sounds like what I wanted. So, the base complexity of an order
> triplet is pretty simple, it will take pow(count + 1, length) crypts()
> to complete. This works when fixed=0, but any other value really
> complicates the calculation. Here is my solution:
Would this be a better fit for Fork/Node (currently available in
contest builds)? I don't understand fully what was just said, but it
seemed like it could apply at a minimum to incremental mode in
fork/node. Magnum currently has that source, while I am
finding/documenting bugs for it (lot's so far fo cygwin). Nonetheless,
sounds like a great addition/patch!
-rich
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.
