[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABh=JRHzjJFr2Lp0s-TKA5PwyoTo-Ab3srKo9_T07BZ-F0=LMQ@mail.gmail.com>
Date: Tue, 6 Mar 2012 10:12:30 +0200
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: RAR format finally proper
Yeah, just setcryptkeys on GPU. I was surprised to learn that unrar binary
is faster for large files. Looks like I need to dig into the clamav rar
code and see what can be improved.
On Tue, Mar 6, 2012 at 10:05 AM, magnum <john.magnum@...hmail.com> wrote:
> 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
>
>
Content of type "text/html" skipped
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.
