Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 06 Mar 2012 09:05:12 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: RAR format finally proper

On 03/06/2012 08:11 AM, Milen Rangelov wrote:
> Great :) Did the memory buffering improve things a lot with your code? I
> was surprised to find out it does not improve performance a lot here :(

I never tested using the files directly because the clamav code lacks
decryption. The last thing I did was moving AES decryption into
rar_unp_read_buf() so now we could actually use an FD if we wanted to.

I think we should mimic the pkzip format: for smallish files, store the
data as hex in the "hash" blob so we have a permanent copy in memory and
never read the file (we won't need the file at all then, just the
rar2john output). This is beneficial for attacking multiple hashes at
once. But this is not an issue until we get OpenCL running :)

> It would be great if you can find out some way to improve checking and
> share it of course :)

I did notice that for a large file (2 MB compressed), spawning unrar is
actually faster than the current code *despite* the fact it will
re-calculate the IV and key from the password another time. This implies
we could improve things a lot. I am almost tempted to try libunrar.so
instead, only hacked so we pass aes key and iv instead of a password.

> As per AES/OpenSSL, I read somewhere they implemented runtime AES-NI
> detection/use. Though I don't think this have made it into the debian
> packages I use yet. It might improve things a lot. 
> 
> I also scan the archive to find the smallest file to crack. I went a bit
> too far by refusing to crack an archive if there is no file smaller than
> 4MB in it, it just becomes so slow. I am really considering to do some
> bulk AES decryption on GPU, however memory and bus bandwidth
> requirements become so bad :(

You currently run just the SHA-1 loop in GPU, right? Anything else would
impose bandwidth challenges I suppose.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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