[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18f7c20887da846e4d37dbdb8721531b@smtp.hushmail.com>
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.
