Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 May 2013 18:11:48 +0530
From: Sayantan Datta <>
Subject: Re: password generation on GPU

On Thu, May 16, 2013 at 4:38 PM, Solar Designer <> 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.


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.