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.