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.