[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
