[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 19 Nov 2011 22:20:10 +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).
2011-11-18 22:28, magnum wrote:
> OK, bare with me now. The above makes sense. But, then, how can hmac-md5
> work as it is written now? In non-SSE mode, it is performed this way
> (first half of hmac):
>
> MD5_Init( &ctx );
> MD5_Update( &ctx, ipad, 64 );
> MD5_Update( &ctx, cursalt, strlen( (char *) cursalt) );
> MD5_Final( (unsigned char *) crypt_key, &ctx);
>
> I have no problem with that. But the current SSE code do the exact same
> thing like this:
>
> SSEmd5body(ipad, ((unsigned int *)dump), 1);
> SSEmd5body(cursalt, ((unsigned int *)dump), 0);
>
> ...and this works. So, in SSE we call the body function twice, as you
> put it, while the non-SSE does not. How come this is not a problem here?
I think I spotted the answer myself. Within MD5_Update, if the new
length is 64 or longer, body() will be called, right? In the above
example this is always true, which explains it all.
Could we add SSExxxUpdate() for intrinsics too without too much hassle?
I have a feeling it could be of great benefit for some salted formats as
we get rid of stuff in the inner loop (see hmac_md5 patch 30 for an
example).
magnum
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.
