[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMNNT=KyNwFGBzCGh+vd+M8vm=WdvcR=ONSioapey9GCgQ@mail.gmail.com>
Date: Fri, 17 May 2013 01:18:52 -0700
From: Myrice Li <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: password generation on GPU
magnum, Sayantan -
On Thu, May 16, 2013 at 5:09 AM, magnum <john.magnum@...hmail.com> 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.
Myrice
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.
