[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABh=JREoDxfBTQaMqf_vKGDsqjiFiz3+24tqOiUbGkj+ofvLZQ@mail.gmail.com>
Date: Mon, 19 Mar 2012 23:20:31 +0200
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: OpenSSL and AES-NI (was: RAR format finally proper)
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).
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 :(
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...
On Fri, Mar 16, 2012 at 10:32 AM, magnum <john.magnum@...hmail.com> wrote:
> On 03/13/2012 02:13 AM, magnum wrote:
> > On 03/07/2012 11:37 PM, magnum wrote:
> >> On 03/06/2012 08:11 AM, Milen Rangelov wrote:
> >>> 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.
> >>
> >> Yeah interesting, it can decrypt a byte in 2 cycles instead of 15... I
> >> suppose you could try using the code supplied by Intel at the end of
> >> this PDF: http://software.intel.com/file/24917 - it even mimics the
> >> OpenSSL interfaces.
> >
> > It seems my standard Ubuntu OpenSSL 1.0.0e has AES-NI configured and
> > enabled out of the box so maybe this is nothing to worry about? I'll
> > benchmark it later on a CPU that actually supports it.
> >
> > Anyway here's a better "version" (the one above is source code in PDF
> > form) of that Intel library, if we ever need one:
> >
> http://software.intel.com/en-us/articles/download-the-intel-aesni-sample-library/
>
> I did some experiments. Linking the Intel lib (referenced above) to the
> RAR format, I get a significant speedup compared to OpenSSL (despite
> I'm still running the key/iv generation in CPU - using OpenCL the boost
> will be even better). But when I run this:
>
> $ openssl speed -engine aesni -decrypt -evp aes-128-cbc
>
> On an Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (lacking aesni):
>
> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192
> bytes
> aes-128-cbc 50781.48k 56127.74k 57736.73k 167606.27k
> 170622.98k
>
>
> On an Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz (with aesni):
>
> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192
> bytes
> aes-128-cbc 633410.88k 2060109.74k 2740870.85k 2959463.09k
> 3014486.13k
>
>
> ...this is 17x faster (both machines using exact same versions of
> everything) so it clearly shows that OpenSSL *can* use AES-NI.
>
> So I suspect the current OpenSSL use in RAR format just fails to
> "enable" AES-NI until we modify it a little. Some googling indicates we
> might have to use the EVP interface in order to get AES-NI from OpenSSL.
> I have still to get that working (I find it backwards that the high
> level interface is much more complicated to use than the low level ones)
> and I suspect this will be slower than the Intel lib anyway because of
> much more overhead.
>
> magnum
>
>
Regards
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.
