[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: aes performance
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: aes performance
- From: John Brooks <special@xxxxxxxxxxxxxxxx>
- Date: Mon, 23 Feb 2009 09:33:48 -0700
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Mon, 23 Feb 2009 11:33:55 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=0alKfU12aX233OG7dLZLPpTOHXwpJdO3nZwmEVyaxPY=; b=YZXmigeKLZCdo/P7TeJ5HQm6UtZ+BO+TVVGfQky+1G19a9G8vL9eAWO8Pud0khNJIh usGEpuJu3I1HQXUWAShpQsrL7i64JwCYYDxSZQs7Qaz79t5x4MyTy1937CLfJC3J2ure Yz6RjlYziMpqoULPeQpdLB5KGlSozLE1l598Q=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=sqLDDlKNKfDrtVMkumqCcqipd8Fqq+bz84jouqyAHpIpQAKn4CbhmnyTM7qZwvG29d jgei2zTmLJLeiV1A9QkNQFi4VRRgFClMnBJNSiuBz4+XsREVj0hFU4WFr83NRYU2QO3u D6jxQ7uCeFOhblxJZY8hXxq8C/1PXHeiFWPq4=
- In-reply-to: <49A2CD79.8030602@xxxxxxxxxxxxxxxxxxxxxx>
- References: <49A158AB.2090703@xxxxxxxxxxxx> <49A2CD79.8030602@xxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxx>
Olaf Selke wrote:It would be nice if Tor was using bigger blocks, but I've not looked at
> 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?
the code yet.
If you're going to replace hardware, hardware assisted encryption may be
> 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
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 bytesaes-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 bytesaes-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.