[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Jan 2013 00:07:37 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: des-opencl
On Mon, Jan 7, 2013 at 11:26 PM, Solar Designer <solar@...nwall.com> wrote:
> There's some confusion here. What exactly did you try? Fully unroll
> the DES rounds loop (all 16 rounds are sequential pieces of code, with
> only the 25-iterations loop around them), but then only substituted some
> fixed key bit indices, continuing to use the key schedule array for the
> rest (even though you no longer had to)? I am not sure we understand
> each other correctly here...
>
#define loop_body()\
switch(k) {\
case 0 :H1_k0();\
if (rounds_and_swapped == 0x100) goto next;\
H2_k0();\
k +=96;\
rounds_and_swapped--;\
break;\
case 48 :H1_k48();\
if (rounds_and_swapped == 0x100) goto next;\
H2_k48();\
k +=96;\
rounds_and_swapped--;\
break;\
default :H1();\
if (rounds_and_swapped == 0x100) goto next;\
H2();\
k +=96;\
rounds_and_swapped--;\
break;\
}
#endif
Here Hx_ky() are hardcoded.
If I'm correct we would need more cases e.g 96,144,192.....upto 720 to
fully harcode the entire loop.
I'm not sure how to keep both (or all three?) approaches in the same
> source tree best, though. 3 formats? Or a format with compile-time
> fallbacks (e.g., use binary patching when the target GPU type is one of
> those where we've tested this and it works, and fallback to E[] for
> other devices?) Perhaps we'll make a "final" determination on that at a
> later time, but for now we simply need to have these available.
>
I'll make a compile time fallback for now if you agree.
Regards,
Sayantan
Content of type "text/html" skipped
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.
