Date: Tue, 20 Mar 2012 12:31:50 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: OpenSSL and AES-NI On 03/19/2012 10:20 PM, Milen Rangelov wrote: > Hello again. > > I tested the Intel AES-NI code (I modified it a bit as it did not follow > the OpenSSL convention that close as it initially appeared to). I was prepared to do such modifications (if you mean padding) but never had to. Have you tweaked block sizes and stuff in the unrar code? You are not decrypting too little at a time, are you? I currently stay at 32KB at a time, the original figure. > To my (unpleasant) surprise, it did not bring the expected performance > gains with RAR. It did bring some small gains when header encryption was > used and indeed helped a lot more when no header encryption was used. > However the latter applies only when you have small files in the archive. > For some reason, this improvement does not scale linearily with the file > size. For small files in the archive I get quite an improvement. When files > in archive are several megabytes in size, the difference is not that huge > at all. And when files get several tens of megabytes in size, it really > does not matter where you use AES-NI or not - speed gets close to zero in > both cases :( I did not test very much. I used a 4 MB file and got a 45% boost (for CPU-only format) with stored files, and 21% improvement with compressed files. I actually saw a 4% drop in -hp mode but I never tried to optimise it at all. I presumed it would be much better with OpenCL key setup but obviously if it comes to tenths of MBs, the decompression will still take a lot of time. You'd need to port the decompression stuff to OpenCL... I tried to profile the AES-NI version of my code, for telling how much was decompress and how much was AES but my version of Valgrind did not support the AES intructions. Later ones do, I'll build one later. I just got SetCryptKeys running with OpenCL, but it's not awywhere near finished so I have my hands full with that for now :-) > Perhaps like more can be achieved by tweaking the RAR decompression routine > in the libclamav code. I am not that happy with the result though, I put so > much hope on AES-NI... I was planning on concentrating on the very first data block, trying to detect invalid dictionaries. And just step the unpack code and see if there are some code paths that are more rigid than we want to. I'd like to think there are huge gains possible but I'm not sure we'll find them that easy. Oh btw, I think I know one thing already, but haven't tested yet. The very first bit of the decrypted data tells you if it's LZSS or PPMII. But I think I saw somewhere in the code that if it was supposed to be PPMII but that engine detects an error, it tries to fall back to LZSS instead of aborting. This kind of behaviour is precisely what we're looking after! Also, I think I saw a suspicious function name in Valgrind that I'll get back to. It was like "restart" something. That too just might be some kind of rigidness we don't want. 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.