Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Mar 2012 00:04:23 +0200
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: RAR format tweaks (was: OpenSSL and AES-NI)

Hello magnum,


> I did some tests and research today that showed that the unrar code
> mostly does what we want it to. This is a good thing, except it means
> the gains I hoped for will probably not be there.
>

In fact I wasn't very much optimistic about it, but it was like my last
hope  :)

So, back to square one. Meanwhile I'm trying to figure out how to deal
> with -p mode best: My current code calculates the AES key and IV in GPU,
> and does the rest in CPU (multi-threaded). I'm not sure how to
> auto-scale OMP vs. GPU for best balance.


That's exactly what I do too. SetCryptKeys on GPU and AES decryption and
decompression on host. That's also what (AFAIK) igrargpu does.



> There's no point in calculating
> 5000 keys in one second if it takes 9 seconds to verify them afterwards.
> You might have one CPU core, or 96 of them.
>

True :)


> For -hp mode this problem could be mitigated by decrypting in GPU, but I
> don't except it to be faster, just "easier". Actually I think -hp mode
> will do just fine with the current code (I haven't tested on GPU yet).
>

I don't think so. With -hp mode, decryption is quite fast related to the
key strengthening part, even if it was performed on a fast GPU. On the
other hand, doing AES in the kernel would increase the GPR pressure even
more. Although it's worth investigating whether writing the key/IVs in
global memory, then running a second AES-only kernel to decrypt the header
using them would make a difference. Anyway, for that small amount of data
to decrypt, I think kernel launch/__global memory latency would be an
overkill.



> Finally, the more I look at the unrar code, the smaller it gets, and I'm
> starting to think I could migrate all of it to OpenCL. Maybe not a one
> beer job though.


IMO that's a bit optimistic.  While I think it's possible, I see a lot of
reasons why porting unrar to opencl would end up a freaking massacre :)
It's just too much branching, too much lookup tables and inability to
vectorize, besides a lot of data needs to be pushed through
clenqueuewritebuffer and then decrypted and decompressed by the kernel. I
think that's challenging thing to do, but it would definitely cost me
weeks, more likely months of efforts (I am doing that in my free time and I
also have a family to take care of :) ).

Well IMO, rar is just evil and I don't think it would take long before I
give up, at least for now. I just wasted so much time on it and it's
getting rather annoying :)

Regards

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

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