Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ