Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Jul 2012 09:54:03 -0700
From: Alain Espinosa <>
Subject: Re: formats interface enhancements

On 7/12/12, Solar Designer <> 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?


> 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

> 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.


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.