[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c1317e0c8e2388087e9a0318ef809cb@smtp.hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
