Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.