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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ