<div>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.</div>
<div><br></div><div>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. </div>
<br clear="all"> - John Brooks<br>
<br><div class="gmail_quote">On Mon, Feb 23, 2009 at 9:23 AM, Arjan <span dir="ltr"><<a href="mailto:n6bc23cpcduw@list.nospam.xutrox.com">n6bc23cpcduw@list.nospam.xutrox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">Olaf Selke wrote:<br>
> hello there,<br>
><br>
> as I understood tor spends most of its cpu time within openssl library aes crypto.<br>
> Which result of "openssl speed aes" applies to tor? Is it aes-128 cbc 16 bytes?<br>
<br>
</div>It would be nice if Tor was using bigger blocks, but I've not looked at<br>
the code yet.<br>
<div class="Ih2E3d"><br>
<br>
> In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to<br>
> be roughly about 40 MBit/s as middleman. Correct?<br>
><br>
> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes<br>
> aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k<br>
> aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k<br>
> aes-256 cbc 69559.47k 92221.78k 102006.05k 105361.75k 100274.74k<br>
><br>
> Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in<br>
> openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node.<br>
> For the sake of better performance I'm thinking about replacing my tor node's<br>
> hardware.<br>
<br>
</div>If you're going to replace hardware, hardware assisted encryption may be<br>
an option. Recent VIA CPUs like the C7 and the Nano can do that. Their<br>
clock frequency isn't very high, so something else (instead of<br>
encryption) may become the bottleneck.<br>
<br>
Resuls for VIA Nano (with 32-bit openssl):<br>
<br>
VIA Nano 1.6 GHz with padlock engine<br>
<div class="Ih2E3d">type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes<br>
</div>aes-128-cbc 69796.09k 275407.68k 585574.57k 815018.33k 920136.36k<br>
aes-192-cbc 52670.82k 208539.14k 472485.55k 691277.82k 798340.44k<br>
aes-256-cbc 50984.77k 201934.27k 439964.25k 623764.14k 709612.89k<br>
<br>
VIA Nano 1.6 GHz without padlock engine<br>
<div class="Ih2E3d">type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes<br>
</div>aes-128-cbc 41429.86k 55836.29k 60886.87k 62508.03k 62974.63k<br>
aes-192-cbc 35838.02k 47521.62k 51671.72k 52854.10k 53177.00k<br>
aes-256-cbc 33208.77k 41789.16k 45009.83k 45891.24k 46153.73k<br>
<br>
Performance for 16-byte blocks is pretty poor, but for bigger blocks<br>
it's much faster.<br>
<br>
A VIA C7 running at the same clock frequency should produce similar results.<br>
<br>
</blockquote></div><br>