[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090910062611.GA5510@openwall.com>
Date: Thu, 10 Sep 2009 10:26:11 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: asking what might happen in future releases
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.
> 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? ;-)
> 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.
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.
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.
