[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <F33E464F2CE94F07B28664D1FC9E723F@ath64dual>
Date: Thu, 5 Nov 2009 19:32:25 -0600
From: "JFoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: My patches (Performance, options, mingw, vc, generic md5, phpass, etc)
As for how the generic MD5 module is coming along:
- 64 bit intrinsic code (so now native 64 bit builds should be able to be
done). This is still being tested. I installed Win7-64 and MinGW-64, but
had problems compiling the intrinsic code on MinGW-64. However, I can build
with an older gcc (but only 32 bit), thus 'should' have all the data
structures and loads working properly. But until I hear that it IS working
properly on 64 bit, I will hold it in the developmental stage.
- 2nd salt (working)
- Constants (up to 8). Makes formats such as Post.Office-md5 work in a
pretty trivial manner. (working).
- Sped up some of the md5_gen() subfunctions (most about 10-15%). Some of
them received significant improvement (such as double speed).
- Added md5_gen(18) (post office md5). It is not quite as fast as the
native, since it is using multiple function calls to append all of the data
in the string, but it is not far off.
One thing I plan on adding, is ability for SSE/MMX code to work with a
double length input buffer. This will allow passwords up to 120 bytes to be
worked on within SSE/MMX, but they should still be MUCH faster than using
the OpenSSL code. Today, all SSE/MMX is limited to 56 bytes. For some of
the generic formats, where they feed md5 base-16 outputs back into inputs,
56 bytes, is too small. John will not be written to flip back and forth
between 1 64 byte buffer and 1 128 byte buffer. It will be run in either 64
byte mode, or 128 byte mode. If the format does not 'fit' in the 64 byte
mode (i.e. some part of the expression crosses the 56 byte boundary), then
the format will always use the 128 byte mode. But there will probably be a
way to allow the user to force john into the 2 buffer (128 byte) mode.
Thus, for formats which do fit (but just barely), and the user wants to test
some longer passwords, then the user would be able to tell john to 'go
large'. I figure there will be a speed hit, but I bet it will be in the
20-30% slower range. That still usually is MUCH faster than the OpenSSL.
Right now, the limits are 56 bytes for SSE, and 125 bytes for OpenSSL. This
would be up'd to 120 bytes for SSE, which will allow it to handle most any
format.
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.
