Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 01 Oct 2013 23:40:11 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: rakp format

On 2013-10-01 11:25, Solar Designer wrote:
> Additionally, both rakp and rakp-opencl process the salt for each
> candidate password individually (unless the OpenCL compiler manages to
> optimize that, which it might).  I think a SHA-1 computation may be
> moved from crypt_all() into set_salt().

I can't see that. In this case, and in our other HMAC-* formats, our key 
is the HMAC key and our salt is the HMAC message - maybe you thought 
about the reverse case? Here's inner loop pseudo code:

	SHA1_Init();
	SHA1_Update(ipad);
	SHA1_Update(salt);
	SHA1_Final(crypt_key);

	SHA1_Init();
	SHA1_Update(opad);
	SHA1_Update(crypt_key);
	SHA1_Final(crypt_key);

The ipad and opad buffers are prepared as much as possible in set_key() 
which gains "many salts".

In SSE2 code path, the salt buffers are prepared once and for all in 
get_salt() which gains a little - but this is only buffer preparation, 
not a SHA-1 computation. I can't see anything more to move out.

However, now that I look at it we could obviously do the two initial 
ipad/opad SHA1's in set_key() too (or leave them in crypt_all() but 
avoid doing them again if keys did not change). Not sure how we could 
miss that for all these years (in the HMAC-formats). This too would only 
gain the "many salts" case but it'd be a good boost. I'll have a look at it.

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.