Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Aug 2012 08:46:38 +0400
From: Solar Designer <>
Subject: Re: bitslice DES on GPU

Sayantan -

On Thu, Aug 16, 2012 at 10:14:35PM +0530, Sayantan Datta wrote:
> What is the use of parameter DES_bs_cpt?

cpt stands for "crypts per thread".  We have these not only for DES, but
also for md5crypt and bcrypt.  It is the relative increase in number of
candidate passwords hashed per call to crypt_all() per thread, as
compared to what crypt_all() does in a non-OpenMP build.  The purpose
for having such an increase is to reduce overhead on thread management
and to let threads run for longer without being forcibly synchronized.
On the other hand, large cpt settings increase the working set size of
crypt_all() (as well as of hash comparisons) and thus may be slower if
things no longer fit in the same cache level.  Also, they may make the
program less interactive.  Hence, some tuning is needed, as well as
consideration of different realistic speeds and salt counts (to ensure
that the .rec file is updated frequently enough).

With a GPU implementation, you will only have one thread on the CPU
side (unless you try to use the CPU for computation as well, which is
tricky), so you will probably not have a cpt parameter in your revision
of the code.  However, if you choose not to use a huge DES_BS_DEPTH
value, you would instead need an array of a large number of structs
similar to DES_bs_combined, and then you'd have some variable or
constant corresponding to this array's size.  It will have some
similarity to cpt, as well as to DES_bs_nt.  On CPU, we need both of
these (and the latter has the former factored into it).  When
interfacing to GPU, you will only need one - and only if you choose to
keep DES_BS_DEPTH low, which you don't have to.


Powered by blists - more mailing lists

Your e-mail address:

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