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


On Sun, Aug 26, 2012 at 01:41:29PM +0530, Sayantan Datta wrote:
> The base address of K[] array gets changed in the opencl kernel. In the
> DES_bs_init() function the addresses stored in of *KSp[] array are derived
> from the address of key bits array K[]. Now when the key bits array K[] is
> transferred to GPU side the base address of the K[] array gets changed
> thereby rendering the addresses stored in *KSp[] array invalid.

If I understand what you're doing correctly, it's not just a change of
base addresses - rather, it's a different address space (CPU vs. GPU
memory) - or do you mean you'd use some DMA buffer, so you care about
the addresses changing still on the CPU side because the buffer is not
located at the same address where K[] was?  I am just trying to come up
with some guess that would match what you wrote, although this sounds
weird to me.

> I'm thinking to transfer a small section of code which generates the *KSp[]
> values to the kernel which should fix the problem.

I thought we had already discussed that, and you were going to use an
array of 768 indices on the GPU side.  The CPU vs. GPU pointers is not
the actual problem, or rather it's a trivial one (I wish we had it).
The actual problem with pointers (as opposed to indices) is that they'd
need to be distinct for each work-item.

This brings us to:

On Sun, Aug 26, 2012 at 11:18:17AM +0530, Sayantan Datta wrote:
> I'm keeping DES_BS_EXPAND=1.

OK.  As discussed, it makes sense to experiment with different
approaches, so I guess you'll try DES_BS_EXPAND=0 next.  (Also, don't
forget that LM hashes imply an equivalent of DES_BS_EXPAND=0.)

So let's suppose DES_BS_EXPAND=1.  In that case, you could do the
expansion on CPU side, but the reason why you won't is that you want to
keep the key setup finalization on GPU.  That's fine.  However, all you
need on GPU to perform the expansion is that constant array of 768
indices; you don't need any pointers, and you don't want to use pointers
for the same reason that would apply in the DES_BS_EXPAND=0 case (the
pointers would differ between work-items and thus would require a lot
more memory total).


Powered by blists - more mailing lists

Your e-mail address:

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