Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Dec 2012 05:34:03 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

On Thu, Dec 06, 2012 at 10:08:05PM +0530, Sayantan Datta wrote:
> Set up two hard coded kernels with same salt. Bit reversed a constant at
> only one position in one of the kernel. Using this loop,
> 
>  //kernel 1
> for(i=0; i< binary_size;i++){
>       iptr = binary + i;
>       if(*iptr== 0xf0000000) printf("Found:%d\n",i);
>     }
> //kernel 2
> for(i=0; i< binary_size;i++){
>       iptr = binary + i ;
>       if(*iptr== 0x0000000f ) printf("Found:%d\n",i);
>     }

Are the above pieces of code running on the host, but for different
kernels?  Are the 0xf0000000 and 0x0000000f constants present somewhere
in the source of those kernels?

> Now comparing the two sets of found locations, I should be able to pinpoint
> at least one  common location. However it seems that there are no common
> location between them!!

You'd need to show (post in here) how you encoded the 0xf0000000 and
0x0000000f constants in the kernels.  Being a fairly large immediate
value, 0xf0000000 probably does not fit in one instruction's immediate
value field (GCN appears to use a 16-bit field for those, and a 12-bit
field for address offsets).  On the other hand, 0x0000000f is small
enough to fit in an immediate offset field or even in a register number
field (GCN allows for encoding of values in the -16 to +64 range in that
way, via impossible register numbers).  So you wouldn't find them as
32-bit immediates.

> Is this approach OK?

Not exactly.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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