Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Sep 2009 16:06:45 +0200
From: rembrandt <>
Subject: Re: asking what might happen in future releases

On Thu, 10 Sep 2009 10:26:11 +0400
Solar Designer <> 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

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


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.