Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Feb 2012 22:07:01 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [JtR PATCH] Support rar's -p mode by spawning external unrar
 process.

On 02/27/2012 08:28 AM, Dhiru Kholia wrote:
> Hi magnum,
> 
> 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 applied this patch to git. I am not overly happy about it but it's
better than nothing. Kinda like the generic crypt format, but worse :)

Anyway, this made me have (yet) another look at rar_fmt. The heavy part
is very straight-forward but it doesn't fit our usual SSE2 stuff because
keys of different lengths will need a totally different number of
64-byte sha-1 calls (we are talking >110,000 calls for one 8-char
password, totalling a length of 7 MB). Just adding OMP to the present
code would be easy but it wont help much.

But as far as I can see it should be fairly simple to do this in OpenCL
(and cRARk already do). It's just a whole lot of SHA-1 updates, half a
million per key. I'm puzzled that you [gpu guys] struggle with bandwidth
problems for raw formats when there are low hanging fruit like this ;-)

We would still have this -p mode problem but with more power under the
hood someone might get the idea to fix that. If I got it right, this is
only about quickly verifying or rejecting the decrypted data, just like
Jim did with pkzip. I bet we can find some situations where we can
reject early, if we just get the full CRC in place first.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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