[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 May 2011 19:50:15 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: John core change patch (and md5-gen, etc)
From: "Simon Marechal" Sent: Sunday, May 08, 2011 3:58 AM
> Le 08/05/2011 04:33, jfoug a écrit :
>> Also, there will be a patch sooner or later ... (27) and (28) (OpenBSD
>> md5)
>
> Ok I didn't read this. I can have a look, that way there would be no
> need to have the intrinsics patch in anything else than md5_gen. I'll
> try to do that during the week.
the md5_gen stuff already has all the #define stuff in it. It does not do
DES, so it does not help there. So, the only thing missing is the
intrisics.c/.h and any patches to the files that get turned into arch.h ?
As for the arch.h, would'nt it be better to have makefile rules that simply
defined MD5_PARA properly, or defined a 'USE_MD5_PARA', and not have to
maintain a whole new set of x86*.h files ? The para was something that IIRC
needed hand tuned, mostly depending upon the 32/64 bit, and what compiler
was being used. However, if we had proper targets in the make file, then we
could set proper defines, and have the arch.h use the define(s) given to it.
One question I have about the intrisic code. Can it do passwords longer
than 54 bytes? Right now, the way I have md5_gen coded, it swiches over to
full non-SSE computations for formats like md5(md5($s).md5($p)) It does as
much as it can using SSE, but then for the final, it simply drops over to
non-SSE mode, accumlates the text string in a flat buffer and calls the
MD5_body() or MD5_go2() function to do it's work. However, I can use SSE
(and plan on it in the near future), to perform this last computation.
However, since the SSE and MD5_PARA code overlap each other (a LOT), if the
MD5_PARA can not do longer than one block computations, it makes coding for
it more difficult. I could get around this problem by using the SSE asm,
but that will only help me in 32 bit builds. If it is a 64 bit build, it is
SSE_PARA or fall back to MD5_body() code, I think.
Well, once this code gets out there for more people to use, and appears to
not need any more babysitting, I will make sure the intrisic stuff gets
addressed, and gets does as efficiently as I can bolt it on to the code.
The SHA1 (for 32 bit asm) has been a royal pain in the arse, due to the
buffers being so different than the MD5 buffers (the input stuff mostly).
It would be great, if the intrisic stuff did not have as huge of
limitations. I think I might take a stab at MD4. I think it will play
rather nicely with MD5, intermixing buffer usage.
I have a pen drive with Unbutu on it now, so can more easily test intrinsic
code, and get it fully working. But this may take some coordination again,
to get a good stable version which builds properly if a user WANTS intrinsic
code, but also builds properly if they do not (such as using GCC, or 32 bit
systems).
Jim.
Jim.
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.
