Date: Thu, 10 Sep 2009 16:06:45 +0200 From: rembrandt <rembrandt@...erlin.de> To: john-users@...ts.openwall.com Subject: Re: asking what might happen in future releases On Thu, 10 Sep 2009 10:26:11 +0400 Solar Designer <solar@...nwall.com> wrote: > On Tue, Sep 08, 2009 at 08:47:33PM +0200, rembrandt wrote: > > I like to ask if the Project (and thus propably mainly Solar) thinks > > about adopting some algorithms to enhance the native support of John. > > Definitely. Yay! :-) > > Do not get me wrong and don't take it as a "I WANT"-request. > > The jumbo-patch is nice and thanks to Benoit Lecocq who made a not yet > > imported FLAVOR to the OpenBSD-port even OpenBSD users can enjoy the > > additional algorithms. > > > > But wouldn't it be better to might include at least some new algorithms > > natively? > > Yes, this is within consideration. > > > And there relies my question (I did not checked yet, I admit): > > ssha, openssha, mysql-sha1, raw-sha1 <- does anything of this shares > > any piece of code? > > > > 4 different algorithms and all are somehow "SHA" thus making me think > > if any of the algorithms added by the jumbo patch shares ANY code if > > they use familiar algorithms and have just minor differences? > > There are several "formats" that use SHA-1 (more than four, actually). > In current revisions of the jumbo patch, some of these call SHA-1 > functions from OpenSSL, whereas some others may also use the assembly > implementation of SHA-1 included in the jumbo patch. In either case, > the SHA-1 implementation itself is shared, not duplicated. > > In older revisions of the jumbo patch, there was also a bundled C > implementation of SHA-1, but I got rid of that because other parts of > the jumbo patch had dependencies on OpenSSL anyway. > > > Thus I think adding some algorithms to the base might be worth the > > effort (also related to further improvements of the algorithms in case > > this happens). > > Right now, all SHA-1 related stuff is in the jumbo patch (and maybe in > other patches) only, with none of it in the official JtR. Thus, there > is no code duplication resulting from the jumbo patch stuff not getting > into the official JtR yet. > > > Solar once told me he lacks time to support further algorithms. > > Well I can imagine that nobody owns each piece of software to get all > > user/PW values thus propably collecting samples with known passwords > > (to test decyphering) might be a sane start. > > There are samples in each *_fmt.c file - the test cases. > > > Are there any plans to enhance the basic functionality of john? > > Are you repeating the same question or did you mean something different > by "the basic functionality" this time? ;-) Well I ment more stuff like the Markov-implementation. Threading or maybe even considering OpenCL implementation of some algorithms. I just think that 8+ core CPUs gonna be avaiable soon. Starting serval john-instances works, also if you combine it with Markov but somehow it should get solved in a way which might be more comfortable. And OpenCL might opens the way to write generic GPU-applications. Specialy the RAW-$algo stuff might profit from this. And during the speedup bigger passwords could get cracked too (7+) in a accaptable time propably. But that are just wild assumptions. > > Also the SSE2 code is great but latest SSE-Engines might be worth to > > get taken care off. Thus this might be another improvement in speed > > like the SSE2 code was. > > Are you going to say that each time you post? ;-) As I pointed out the > last time you said that, there did not appear to be anything exciting > beyond SSE2 in x86 CPUs available on the market. It appears that this > has not changed since then. According to Wikipedia articles I've just > checked, CPUs with relevant additions to the SIMD instruction sets are > due for production in 2010-2011. I'd exspect first CPUs within the first half of 2010. > It might be possible to make reasonable use of a few SSE3/SSE4* > instructions in a few "obscure" places, but I would not expect a major > speedup from that. Well would you asume some speedups during the 256bit SSE engines? > Alexander Regards, Rembrandt
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.