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 <>
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:



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.


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.