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.