[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090910160645.b39a86d8.rembrandt@jpberlin.de>
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.
