[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
