[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41A771EB6D1C47E8A7231413320C8FBA@D9VGLK61>
Date: Thu, 17 Nov 2011 08:38:18 -0600
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: hmacMD5 and sse-intrisics.c (Bartavelle, please look at this).
I did a test case, (offline), and made the changes needed. Now, we can get any of the body's to init or reload, and to view the output as 16byte interleaved output, or 64 byte interleaved input.
For this, if init&1 then we init with default values, else we reload from the out pointer.
if init&2, then the out (which can be the vector input also) is in input format (i.e. interleaved 64 byte), else out is in 16 byte 'output' format.
The change was not too signficant. There is still just a simple if() / else at the start of the body, and the if() / else at the tail end of the body.
For hmacMD5 there was not a huge performance gain. A few percent was all I gained. However, I was only able to test with sse-intrisics.c which runs about 40% the speed of the proper ICC built version, for my 32 bit system. However, it did get better performance, and it made the code within the crypt-all loop MUCH cleaner for hmacMD5. I did need to work with 2 input/output buffers however. I think the code was like this
md5sse(ipad, crypt2, 2)
md5sse(salt, crypt2, 3)
md5sse(opad, crypt, 2)
md5sse(crypt2, crypt, 3)
That code is from memory. I am out, away from my computers where I can do anything on john for a week or so.
We probably should like at getting md5/4 and sha1 working with similar interfaces within the intrisic. Especially now that we have good intrisics, even for 32 bit builds.
Jim.
From: "Simon Marechal" <simon@...quise.net>
> On 16/11/2011 22:14, jfoug wrote:
>
>> I have put a patch on the wiki, but I really want Simon/Bartavelle to have a look to make sure things are correct. I have not tested MD4, but I would be very surprised if that code did not also require the same type change.
>
> I did not test it, but it looks fine to me. I'm not sure why the code
> was in such a state in the first place. I have not looked at it for so
> long that it is all out of my head now ...
>
>> If init==1 or init==0, then keep same logic. This will keep all existing code working 100% same as it is today.
>>
>> If init==2, then init the base vector from 'defaults'. However, write data to out in input format (64 byte interleaved buffers).
>> If init==3, then init the base vector from the out pointer, but out is in input format. Also in this mode, we write to out, but do so in input format (64 byte interleaved buffers).
>
> This is probably what you intend to do, but I suppose using #define'd
> flags would clarify things a lot.
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.
