![]() |
|
Message-ID: <9ff2c4f68c2723a84b4ff136d2e1ace1@smtp.hushmail.com> Date: Sat, 03 Mar 2012 02:38:55 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Re: [JtR PATCH] Support rar's -p mode by spawning external unrar process. On 03/02/2012 02:35 AM, Milen Rangelov wrote: > I've done that in my project (accomodating code from unrar). Is that hashkill or another project? Can we use parts of this code? > 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. I'd be quite happy just to have it running at all without spawning unrar, on CPU. Then we go from there. > 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. If I could get the AES decryption to show any significance in profiling, I would be delighted :) But things might look completely different on GPU of course. What figures are you getting for -hp mode on GPU? 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.