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.