aes performance

[John Brooks]

You're mistaken here. AES *always* has a block size of 128 bits (it was one
of the requirements for the competition to create the AES standard). The
algorithm on which AES is based (Rijndael) can support 192 or 256 bits, but
this is considered nonstandard today, and does not provide any provable
benefit to security. The variable in AES that we usually refer to (as in
aes-128) is the key size. Smaller key sizes mean a smaller key space
(technically, easier to bruteforce, but still unreasonably hard at present),
but they are also dramatically slower. If I recall correctly, aes-192 is
almost 50% slower than aes-128 and aes-256 is an additional 15-25% (but I
don't have a source for those numbers at this time). AES-128 is still
considered secure.

All of that aside, the encryption speed is a non-issue here. Unless you're
using a large portion of a gigabit connection, AES will work far faster than
your line speed on a modern processor. Additionally, just measuring the
speed of that algorithm is very far from the entire story; there are MACs
involved and tor has its own things that need to be applied, including
layers of encryption. Still, I don't see encryption being a large issue for
any but low-powered machines with high bandwidth connections.

 - John Brooks

On Mon, Feb 23, 2009 at 9:23 AM, Arjan
<n6bc23cpcduw at list.nospam.xutrox.com>wrote:

> Olaf Selke wrote:
> > hello there,
> >
> > as I understood tor spends most of its cpu time within openssl library
> aes crypto.
> > Which result of "openssl speed aes" applies to tor? Is it aes-128 cbc 16
> bytes?
>
> It would be nice if Tor was using bigger blocks, but I've not looked at
> the code yet.
>
>
> > In this case my old Prestonia P4 Netburst Xeon box's throughput is
> supposed to
> > be roughly about 40 MBit/s as middleman. Correct?
> >
> > type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> > aes-128 cbc      84098.99k   119729.69k   138053.97k   142741.16k
> 144386.04k
> > aes-192 cbc      75035.35k   104143.72k   115681.81k   120099.84k
> 120949.42k
> > aes-256 cbc      69559.47k    92221.78k   102006.05k   105361.75k
> 100274.74k
> >
> > Strange to say that my desktop Core2 Duo E8400 @home performs only 33%
> better in
> > openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor
> node.
> > For the sake of better performance I'm thinking about replacing my tor
> node's
> > hardware.
>
> If you're going to replace hardware, hardware assisted encryption may be
> an option. Recent VIA CPUs like the C7 and the Nano can do that. Their
> clock frequency isn't very high, so something else (instead of
> encryption) may become the bottleneck.
>
> Resuls for VIA Nano (with 32-bit openssl):
>
> VIA Nano 1.6 GHz with padlock engine
> type         16 bytes    64 bytes   256 bytes  1024 bytes  8192 bytes
> aes-128-cbc  69796.09k  275407.68k  585574.57k  815018.33k  920136.36k
> aes-192-cbc  52670.82k  208539.14k  472485.55k  691277.82k  798340.44k
> aes-256-cbc  50984.77k  201934.27k  439964.25k  623764.14k  709612.89k
>
> VIA Nano 1.6 GHz without padlock engine
> type         16 bytes    64 bytes   256 bytes  1024 bytes  8192 bytes
> aes-128-cbc  41429.86k   55836.29k   60886.87k   62508.03k   62974.63k
> aes-192-cbc  35838.02k   47521.62k   51671.72k   52854.10k   53177.00k
> aes-256-cbc  33208.77k   41789.16k   45009.83k   45891.24k   46153.73k
>
> Performance for 16-byte blocks is pretty poor, but for bigger blocks
> it's much faster.
>
> A VIA C7 running at the same clock frequency should produce similar
> results.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20090223/b75f385f/attachment.htm>