[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7f685004231674fde9a6f4b19f00158@smtp.hushmail.com>
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.
