[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <407b5fd03122dc1cf2ff26c2774ee72c@smtp.hushmail.com>
Date: Fri, 30 Mar 2012 23:18:38 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On 03/30/2012 10:22 PM, myrice wrote:
> On Thu, Mar 29, 2012 at 9:01 PM, Solar Designer <solar@...nwall.com> wrote:
>>
>> Please see above as it relates to not resending the same candidate
>> passwords. As to the salts, with the current interfaces they have to be
>> sent one by one by crypt_all(), and that's sort of fine - these data
>> transfers are tiny and you interact with the GPU at that time anyway
>> (you ask it to go ahead and process the previously provided bunch of
>> candidate passwords with the next salt). There's room for improvement
>> here, but it's primarily about not interacting with the GPU at these
>> times at all (so it's not a trivial improvement to make), not about
>> avoiding those tiny data transfers.
>
> Yes, I mean what you said. We can compute all combination of salts and a
> bunch of password with invoke one kernel. So for benchmark, we have to add
> a bench_set_salts for that? I don't know if it good to change the interface
> at this time. However, I will test for the performance.
Are you saying you want to change the salt interface so you can loop
over all loaded salts without leaving GPU?
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.
