Date: Fri, 11 Sep 2009 01:45:28 +0200 From: rembrandt <rembrandt@...erlin.de> To: john-users@...ts.openwall.com Subject: Re: asking what might happen in future releases On Fri, 11 Sep 2009 02:29:52 +0400 Solar Designer <solar@...nwall.com> 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: > > http://dango.chu.jp/hiki/?Bitslice+XOP 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 -- rembrandt <rembrandt@...erlin.de>
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.