Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Jan 2013 14:51:04 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: des-opencl

>
> Hi Alexander,


On Mon, Jan 7, 2013 at 9:01 AM, Solar Designer <solar@...nwall.com> wrote:

> Another curious detail about mysterymath's implementation is that it
> obviously exceeds instruction cache, yet is reasonably fast on GCN.
> We should try that too as it avoids pointer indirection and reduces
> register pressure due to hard-coding key bit indices (no key schedule
> array needed anymore).  Lukas reported very poor performance on 5850,
> though.
>

Yes I tried that too, but speed was far worse due to hardcoding. Although I
tried this by hard-coding only k=0 and k=96 , there was a huge performance
drop, probably due iCache overrun. To fully hard-code the kernel we need to
do that for k=0 to 720 with a gap of 48 which should be around 16 times
more code(instructions) than we currently have in the kernel.

The speed seen during actual cracking is a lot lower - about 1M c/s,
> not 44M c/s as --test would suggest (this is for many salts).  Why is
> that?  How to avoid this problem?


If you check the speed just after it starts, it should be quite low. It
should increase rapidly after the compilation of all kernels with different
salt is finished. In fact I didn't had much free time lately to fully
implement the binary patch. Hopefully I would be able to complete it in a
week or two.

Regards,
Sayantan

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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