[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 May 2013 18:11:48 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: password generation on GPU
On Thu, May 16, 2013 at 4:38 PM, Solar Designer <solar@...nwall.com> wrote:
> Alternatively, if you have free time now, how about you put some of it
> into improving the quality of your code already in bleeding? Try to
> correct things such as weird/inconsistent indentation, having too many
> global symbols, weird naming, etc. I'm not sure if you notice those or
> not, though.
>
I'll try to solve this. BTW is there any tutorial regarding indentation etc
which I should try to follow.
I intend to provide some mentoring on this during the summer, but I am
> not available for it right now. So any mask mode code you may write now
> would be a throw-away experimental implementation, for you to gain
> experience. This may be fine.
>
Oh, at first I misread what you wrote above. You're asking not whether
> to generate keys on host vs. GPU (the short answer to which is that we
> should do both of these things), but whether to do the GPU portion of
> key generation inside the format or with code shared between formats.
> So far, we only considered doing it from the same kernels that do the
> crypto, so we'd have duplicate implementations of the GPU side of mask
> mode (one for each fast hash format). I think that for mask mode this
> is in fact what we should be doing, and those duplicate implementations
> will end up having enough format-specific optimizations for the code
> "duplication" to be worth it. (Ditto for code responsible for comparing
> computed vs. loaded hashes, using bitmaps and such.) We may also have
> generic implementation(s) (or portions thereof), to be #include'd from
> multiple per-format OpenCL kernels. Using separate kernels (with
> communication via global memory?) is likely slower.
>
Okay, I'll play around with those stuff for now, maybe get start with the
new format in bleeding.
A kernel can call another kernel iirc so it might not be too bad. Maybe try
> it out? It could simplify shared use.
>
This is interesting. I would try out a few toy examples.
Regards,
Sayantan
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.
