[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150523161111.GA599@openwall.com>
Date: Sat, 23 May 2015 19:11:11 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: cycle around crypt_all() body in raw-sha512
Aleksey,
On Sat, May 23, 2015 at 06:45:11PM +0300, Aleksey Cherepanov wrote:
> My guess: switching between crypt_all() and candidate generation
> in self tests is costly due to code cache, the cycle in crypt_all()
> smooths it. Any comments?
I've been using this "trick" in JtR since 1997 or so, initially for
non-bitslice DES. Many of our formats use it. In many cases, it helps
keep both key setup and salt setup out of the loop. Even when not, it
may also help by amortizing the function call overhead. I think it's
not about code cache in your case (you've got a decent N-way associative
code cache), but about the function call overhead being higher than the
loop overhead. You're reducing the total number of calls to crypt_all()
and perhaps to cmp_all() that the program needs to make to test a given
number of candidate passwords. Also, with the loop being within a
function body, some variables may remain cached in registers across loop
iterations - something that would be inconsistent with the ABI for
function calls.
Alexander
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.
