[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EC41F78.4060502@hushmail.com>
Date: Wed, 16 Nov 2011 21:39:20 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: hmacMD5 and sse-intrisics.c (Bartavelle, please look
at this).
Great! I will re-build the .S files and post a patch.
magnum
2011-11-16 21:08, jfoug wrote:
>> From: magnum [mailto:john.magnum@...hmail.com]
>>
>> That's beyond me. I presume calling SSEmd5body() with a zero as last
>> argument is equiv of "noinit" but I'm not sure where to put what
>
> This thread was from research taken from private email, working on getting hmacMD5 format working for SSE2i, but has now been brought back to the list, since there are other 'core' files needing worked on.
>
> This was the type of problem:
>
> SSEmd5body(ipad, ((unsigned int *)dump), 1);
> SSEmd5body(cursalt, ((unsigned int *)dump), 0);
>
> and (32bit md5-mmx.S)
>
> mdfivemmx_nosizeupdate( dump, ipad, 64);
> mdfivemmx_noinit_uniformsizeupdate( (unsigned char *) crypt_key, cursalt, total_len + 64);
>
> should have had dump == crypt_key, but no matter what I did, the code did not equate. NOTE, in the SSE2i code, I did properly setup the length field within cursalt. This is easily validated by dumping cursalt prior to the call of SSEmd5body on the SSE2i build, and dumping cursalt 'after' the call to mdfivemmx_noinit_uniformsizeupdate in the 32 bit .S code. The code was done properly so that they lined up. However, the results were NOT the same.
>
>
>
> Found the problem. The problem is in sse-intrisics.c, so we will NEED to get new .S files built also (this is one reason for this onlist email).
>
> Here is the change I had to make to the bottom of SSEmd5body(), and which I am 90% sure also needs to be made to SSEmd4body(). I looked at SSEsha1body (which 'works'), and found out how it was working there, and moved the code into the md5 body function, and things worked correctly with that change.
>
> This is the original code:
>
> MD5_PARA_DO(i)
> {
> a[i] = _mm_add_epi32(a[i], _mm_set1_epi32(0x67452301));
> b[i] = _mm_add_epi32(b[i], _mm_set1_epi32(0xefcdab89));
> c[i] = _mm_add_epi32(c[i], _mm_set1_epi32(0x98badcfe));
> d[i] = _mm_add_epi32(d[i], _mm_set1_epi32(0x10325476));
> _mm_store_si128((__m128i *)&out[i*16+0], a[i]);
> _mm_store_si128((__m128i *)&out[i*16+4], b[i]);
> _mm_store_si128((__m128i *)&out[i*16+8], c[i]);
> _mm_store_si128((__m128i *)&out[i*16+12], d[i]);
> }
>
> This code was changed to be this:
>
> if (init) {
> MD5_PARA_DO(i)
> {
> a[i] = _mm_add_epi32(a[i], _mm_set1_epi32(0x67452301));
> b[i] = _mm_add_epi32(b[i], _mm_set1_epi32(0xefcdab89));
> c[i] = _mm_add_epi32(c[i], _mm_set1_epi32(0x98badcfe));
> d[i] = _mm_add_epi32(d[i], _mm_set1_epi32(0x10325476));
> _mm_store_si128((__m128i *)&out[i*16+0], a[i]);
> _mm_store_si128((__m128i *)&out[i*16+4], b[i]);
> _mm_store_si128((__m128i *)&out[i*16+8], c[i]);
> _mm_store_si128((__m128i *)&out[i*16+12], d[i]);
> }
> } else {
> MD5_PARA_DO(i)
> {
> a[i] = _mm_add_epi32(a[i], _mm_load_si128((__m128i *)&out[i*16+0]));
> b[i] = _mm_add_epi32(b[i], _mm_load_si128((__m128i *)&out[i*16+4]));
> c[i] = _mm_add_epi32(c[i], _mm_load_si128((__m128i *)&out[i*16+8]));
> d[i] = _mm_add_epi32(d[i], _mm_load_si128((__m128i *)&out[i*16+12]));
> _mm_store_si128((__m128i *)&out[i*16+0], a[i]);
> _mm_store_si128((__m128i *)&out[i*16+4], b[i]);
> _mm_store_si128((__m128i *)&out[i*16+8], c[i]);
> _mm_store_si128((__m128i *)&out[i*16+12], d[i]);
> }
> }
>
> Once this change was made, then things like:
>
> SSEmd5body(ipad, ((unsigned int *)dump), 1);
> SSEmd5body(cursalt, ((unsigned int *)dump), 0);
>
> Now works fine, and the proper MD5 for "ipad"."cursalt" is returned.
>
>
> 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.
>
> NOTE, I have only tested the hmacMD5 change, in the .C file. The .S file(s) I have are both built off of the prior code, thus they fail right now in hmacMD5. But hopefully, magnum will be able to update the .S files here shortly (I do not have ICC).
>
> 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.
