[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Jan 2006 23:17:48 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: roadmap
This posting is in response to several private e-mails I've received,
but I'll also comment on what was actually mentioned on the list:
On Fri, Jan 27, 2006 at 01:04:05PM +0100, Rembrandt wrote:
> On Fri, 27 Jan 2006 11:50:10 +0000 (UTC) Phantom <phantom_otw@...oo.com> wrote:
> > *dreaming of that x86-64/SSE optimization for windows builds.....* ;)
>
> *dreaming of the usage of more then one CPU and SSE* :-D
Actually, I don't think an x86-64/SSE hybrid would be any good for AMD
CPUs. I had mentioned this with Intel's EM64T in mind. While it's the
same instruction set, it's only Intel CPUs which appear to benefit from
the use of SSE for this application so far. AFAICR, both Phantom and
you have AMD CPUs - so you might want to dream of something better. ;-)
An x86-64/MMX hybrid _might_ be beneficial for AMD CPUs as well, but I
am really not planning to work on either any time soon.
Plain SSE (not mixed with x86-64 code) is planned for 1.8, to benefit
Intel P4 CPUs (including P4 Celerons and P4 Xeons).
As it relates to built-in SMP and SMT ("hyperthreading") support, we'll
see. Yes, this is being asked for.
Also, official support for more hash types or other ciphers might be
added, but I'd like to clean up the current code first. One thing which
stops me from integrating support for raw MD5 and the like right away is
that the trivial implementations are far from optimal and I don't have
the time to create an optimal one right now. I realize that people are
(ab)using John the Ripper as a kind of a general-purpose benchmark for
different computer systems and also to estimate the time it'd take to
crack various hash types. Maybe I should workaround this by flagging
the various supported hash types as "optimized" or "unoptimized" (right
in "john --test" output).
Speaking of the cleanups, I am considering renaming the "incremental"
and "single crack" modes and the "formats". I feel that these words are
inappropriate, but they're still there for historical reasons.
Opinions and suggestions are welcome.
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
