[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKtfLcsNOC41SFiLPwZJSjA7SVGtEjiBq53GS-CFch5CQFP-4A@mail.gmail.com>
Date: Thu, 12 Jul 2012 09:54:03 -0700
From: Alain Espinosa <alainesp@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: formats interface enhancements
On 7/12/12, Solar Designer <solar@...nwall.com> wrote:
> ... code ....
> This would work, but it complicates formats that don't actually want to
> take care of these things on their own. We'd need to be providing ways
> for those to leave such things for shared code - functions, macros.
I think we can implement a generic "format_crack" function that calls
existing format functions. If some format needs more control it can
implement a custom "format_crack". I think you propose something
similar to this.
>> Probably more contributors will contribute to ways to generate candidate passwords.
>
> I don't see how your proposal makes this any more likely. Cracking
> modes are already separate from cracker.c's general/shared code.
>
> Well, if we expand multi-threading to upper layers all the way to
> cracking modes, then yes those will become more complicated to
> implement, and your proposal might hide some of this complexity,
> although your get_candidate_keys() would need to be thread-aware
> somehow so that if 2+ simultaneous calls to it are made these return
> different sets of keys. Interrupt/restore may be a bit trickier than it
> is now under either interface, and threads may need to be synchronized
> once in a while under either interface unless we're OK with storing
> per-thread checkpoints and not being able to adjust thread count when
> restoring.
Yes, i was thinking to use multi-threading in all layers.
>> Also we are free to use any optimization in a GPU implementation.
> ...As to get_candidate_keys() in your example it is on CPU anyway, right?
Yes.
> Or do you mean that some GPU format would skip calling it, or would
> modify/multiply the returned keys e.g. by applying a mask on top of
> them? If so, there would need to be a way for the CPU code and for the
> user to expect and control such behavior.
I propose "get_candidate_keys()" to use different "protocols" (so
there is more than one get_candidate_keys() for each cracking mode)
and not only and array of strings. Its a little more complex to
implement but can be very efficient.
> BTW, how does this compare to what Hash Suite uses currently, and to
> what you intend to implement there in the future?
Hash Suite basically uses this architecture, but with a lot more
implementation details.
> I think you don't have perfect multi-threading like this in there yet (with only one
> thread generating the candidates currently, albeit in parallel with
> other threads doing the hashing)...
In the developing version of Hash Suite there is almost perfect
multi-threading. It was relatively simple to implement using
"protocols".
> ...so perhaps this is something you're
> merely considering now rather than have already tried out and recommend
> from experience?
When i begin developing Hash Suite the first idea was this, use an
architecture at "inverse" of john. Besides all the discussion I like
that when implement a new format i call functions like an API, the
other way feels "weird", but this only my opinion.
saludos,
alain
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.
