Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Apr 2012 19:12:31 +0530
Subject: Re: GSoC Project proposal:JtR GPU for Slow hashes

Hi Alexander,

> Fixing this is something you could work on, yes.  If there's any
>> performance impact from such fixes (for newer GPUs that don't need the
>> fixes), then both versions of the code should be present (but without
>> duplication of source code shared between the versions).
I think only the kernels would require two different versions.

>     Several of them build upon PBKDF2 with
>> SHA-1 (and for Mac OS X 10.8 apparently we'll need PBKDF2 with SHA-512,
>> but I haven't looked into that yet), so that's one thing to have and to
>> optimize really well.
As of now I will modify the PBKDF2 step and optimize it as much as I can.
But later ,I'm considering reimplementation of the PBKDF2 step from scratch
keeping in mind all  possible optimizations from the beginning.  On the
newer GPUs I will have much more flexiblity than current one.

> Similarly, the existing OpenCL and/or CUDA code needs to be optimized
>> further.  Lukas said that this is what he intends to apply for under
>> GSoC, but that does not prevent you from offering to work on it as well.
That would be great as we could learn a lot from each other.

> Thank you for suggesting this.  I think it'd be best if you test your
>> code on multiple GPUs as you develop - not postpone porting to another
>> GPU family as a separate task.  It'd be nice if you could get more than
>> two GPUs - not just 4000 series vs. newer, but also Nvidia.  I realize
>> that buying lots of GPUs is costly, though.
I could only buy one GPU but you are welcome to suggest the brand.  (As a
Radeon fanboy I am a little biased toward it.:) )

> Multi-GPU support within one instance of JtR would be very nice to have.
>> There are two major approaches to this, I think: high-level (similar to
>> what we have with MPI now) vs. per-format (similar to our current OpenMP
>> stuff).  It might be best to support both (they have their pros and cons).
>> This deserves its own discussion thread, though.
I'll discuss this topic for later on a seperate thread.



Content of type "text/html" skipped

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.