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.