Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Mar 2012 23:18:38 +0200
From: magnum <>
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 <> 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?


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.