Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 22 Sep 2012 01:49:48 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

On Sat, Sep 22, 2012 at 1:44 AM, Sayantan Datta <std2048@...il.com> wrote:

>
>
> On Sat, Sep 22, 2012 at 1:41 AM, Sayantan Datta <std2048@...il.com> wrote:
>
>>
>>
>> On Sat, Sep 22, 2012 at 12:51 AM, Solar Designer <solar@...nwall.com>wrote:
>>
>>> Hi Sayantan,
>>>
>>> On Sat, Sep 22, 2012 at 12:31:26AM +0530, Sayantan Datta wrote:
>>> > I was experimenting with DES_BS_EXPAND set to 0 and using different
>>> types
>>> > of memory .
>>> >
>>> > 1. B[] in local memory and K[] in private register space:
>>> > With this combination I'm getting speeds of around 24M c/s on 7970 and
>>> 5M
>>> > c/s on 570.
>>> >
>>> > 2. B[] in private register space and K[] in local memory
>>> > I'm getting 12M c/s on 570 while I couldn't get it working on 7970.
>>> Getting
>>> > hash fails every time. Most likely the problem is with referencing B[]
>>> > array in z(p) macro.
>>>
>>> That's curious.  Even more interesting would be speed numbers with the
>>> overhead mostly excluded - that is, use this test vector:
>>>
>>>         {"..X8NBuQ4l6uQ", ""},
>>>
>>> set the iteration count e.g. to 2501 (any odd value should do), and
>>> multiply the reported c/s rate by 100 (if you picked 2501) to get the
>>> descrypt equivalent cracking speed.
>>>
>>> As to the overhead, we'll need to deal with it by other means later.
>>>
>>> I just did some math, and I think that your 24M with overhead may
>>> correspond to around 65M in the without-overhead test.  Please confirm
>>> or disprove. ;-)
>>>
>>> 1/(1/39+1/41) = 19.99
>>>
>>> 1/(1/39+1/60) = 23.64
>>> 1/(1/39+1/65) = 24.38
>>>
>>> 39M is my guess as to the "overhead speed" alone (without crypto), based
>>> on the 19.9M "with overhead" speed you reported and my 41M
>>> without-overhead test.  Assuming that this "with overhead" speed
>>> remained the same, it'd take around 65M without-overhead speed to
>>> reach/exceed 24M reported for overhead+crypto.
>>>
>>> Thanks,
>>>
>>> Alexander
>>>
>>
>> Hi Alexander,
>>
>> In the previous test Global no. of work items were half of this time. So
>> the overhead is double in this test than the last one.
>> Setting 2501 I'm getting 35M without any overhead. So your guess of 65M
>> is accurate.
>>
>> here's the math:
>>
>> 1/(1/(39x2) +1/65) =35.4
>>
>> Regards,
>> Sayantan
>>
>
> Sorry my math is wrong. Result is weired.
>
> Regards,
> Sayantan
>

Here's the correct one:

1/(1/78 + 1/35) = 24

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