Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 May 2013 01:18:52 -0700
From: Myrice Li <>
Subject: Re: password generation on GPU

magnum, Sayantan -

On Thu, May 16, 2013 at 5:09 AM, magnum <> wrote:
>  > 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.
> A kernel can call another kernel iirc so it might not be too bad. Maybe
> try it out? It could simplify shared use.
> magnum

A kernel can call another kernel only with same configuration(thread/block
number) before Kelper(sm_35 iirc). So it may not feasible to have this. But
it is also depends on implantation. It is worth to have a try.


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.