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

On Fri, 11 Sep 2009 02:29:52 +0400
Solar Designer <> wrote:

> On Thu, Sep 10, 2009 at 04:06:45PM +0200, rembrandt wrote:
> > Well I ment more stuff like the Markov-implementation.
> I do not intend to include the specific implementation that is currently
> in the jumbo patch.  If I have time (which sounds unrealistic), I
> might do some testing, then either enhance the "incremental" mode or
> introduce a new cracking mode.
> > 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.
> So basically you're just pinging me to resume work on JtR, as usual. ;-)

Well if it wouldn't be you I wouldn't think that anybody can make some
unrealistic stuff do come real. But 'course you suprised in the past I
simply count on that... 

And you're simply somehow the only maintainer ([jumbo]patches don't
count now)... ;-)

The Markov-model sounds promising for me to use multiple cores for a
single task. Even I don't doubt about the implementation quality.

*quick idea during drinking vodka*
Maybe recent statistical analyses would support any effort?
Amount of a charackter for a specific language or so?

Today such informations could get gathered and proceeded more easily.
I can imagine that different languages have different charackters and
thus "more likely" combinations.
So if I know the passwordfile is from poland I might could specify
-lang=pl and gain a simply modified logic then the default one (which
is likely based on US-EN, or?)

About the OpenCL stuff: That sounds damn promising Solar!
Of course OpenCL aint supported at OpenBSD...
But I am sure that ongoing efforts in X will make it possible.
I would consider OpenCL as "specific" enhancement which would just work
on Linux/MacOSX and Windows then for now.
But the Altivec-enhancement do work on PPC only either.
It's how I would see it. But the speedsup which would be possible would
rock. Even with a awesome bad implementation.

And I don't mean CUDA or Brooks but OpenCL.
It's in BETA-phase now as far as I see (nVidia/ATI drivers).

> > Well would you asume some speedups during the 256bit SSE engines?
> I am not sure about the 256-bitness specifically - it may be twice
> faster than 128-bit "as it should be", or it may be the same, or it may
> be slower - depends on implementation (specific CPU).  (For example,
> 128-bit SSE bitwise ops as originally implemented in Pentium 3 were
> actually slower than 64-bit MMX per-bit.)
> However, there are two other relevant improvements - 3-op instructions
> and the vpcmov instruction, which is similar to AltiVec/Cell vsel/selb.
> These are obviously usable for bitslice DES (and more), and in fact this
> has already been shown - I just happened to find that by doing a Google
> search for "vsel selb pcmov" (without the quotes) or something like
> that (I did several searches to confirm that the new instruction will in
> fact be similar to vsel/selb).  Here's what I found:

Thanks! The INTEL documentation is somehow less logical then the
documentation from AMD about what their CPUs can do and how many
registers they have. Or I might look at the wrong PDFs...
> Alexander

Thanks for the informations Solar!

And if you might have some time in the future:
What are your ideas, plans? Can the cummunity help or not...
Maybe it would be time for a lil statement about what you've in mind.

I would love to read it and maybe it attracts other developers. :-)

Best regards to you and kind regards to everybody else,
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.