Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ