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

Your e-mail address:

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