[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABh=JRHnWvJq4+TWF141GAu-BgM0h6_9hp3JC2QVoJ_=6+o0FA@mail.gmail.com>
Date: Thu, 1 Mar 2012 20:38:37 -0500
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: [JtR PATCH] Support rar's -p mode by spawning
external unrar process.
Ah yes, and the RAR opencl kernel is real pain. I had to split it in 16
different kernels for each password length (16 is the max len with my
program). I lost weeks until I optimized it and I am still not glad with
the speed (igrargpu being somewhat faster). It's just that register
pressure is too high. What I found out is that keeping some data in __local
rather than __private helps a lot in that case. Also, no uchar whatsoever
with that byte addressable extension, that's just slow as hell. Using uints
with some bitwise magic is much much faster...
On Thu, Mar 1, 2012 at 8:35 PM, Milen Rangelov <gat3way@...il.com> wrote:
> I've done that in my project (accomodating code from unrar).
>
> It's just evil. Not that bad on CPUs because setcryptkeys is the real big
> bottleneck there, but on GPUs speed can get 10 times or even slower as
> compared to -hp mode. I also know your work on ZIP, borrowed the idea from
> you if you don't mind :) But in reality, RAR is worse. Statistically, for a
> ~300KB file in archive, somewhat ~60-70% of the candidates do decompress
> without an error until they get ruled out by the crc check. It's bad.
>
> Funny thing I found experimentally is that AES decryption is the bigger
> problem in my code (I use OpenSSL's routines). I am really thinking of some
> way to do that on GPUs for the first chunk read, but again that's not very
> much useful. I guess a fast, AES-NI accelerated decryption routine would
> probably make some difference.
>
> I also do some prebuffering in case archived file is small enough, but
> that does not bring much difference (contrary to what I expected).
>
>
> On Thu, Mar 1, 2012 at 7:46 PM, magnum <john.magnum@...hmail.com> wrote:
>
>> On 02/27/2012 10:07 PM, magnum wrote:
>> > On 02/27/2012 08:28 AM, Dhiru Kholia wrote:
>> >> Until someone figures out how to crack rar's -p mode, the attached
>> >> patch should work. It spawns unrar process for RAR files encrypted
>> >> with -p mode.
>>
>> I am not much closer to really fixing -p mode but I committed a patch
>> that make it work for -m0 (stored) files without spawning unrar. I also
>> found a 15% boost for LE systems with no alignment requirement. Also
>> fixed a memory leak in set_salt().
>>
>> I also changed rar2john to pick best candidate from RAR file: Prefer
>> stored files over compressed, and prefer smaller files over larger.
>>
>> Like Rich said, 7z might be the best code to use for inflating. But like
>> all other alternatives I've found, it's object oriented code. This slows
>> me down considerably, possibly to the point I'll give up :(
>>
>> magnum
>>
>>
>
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.
