Re: aes performance

[Arjan <n6bc23cpcduw@xxxxxxxxxxxxxxxxxxxxxx>]

coderman wrote:
> On Mon, Feb 23, 2009 at 8:23 AM, Arjan
> <n6bc23cpcduw@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> ...
>> It would be nice if Tor was using bigger blocks, but I've not looked at
>> the code yet.
> 
> i think you mean buffers (or at least multiples of 16 byte blocks);
> and yes the 4096 byte or larger buffers would be nice to get the most
> of the "rep" style XCRYPT instruction chaining.

Yes, that's what I meant.


>> ...
>> clock frequency isn't very high, so something else (instead of
>> encryption) may become the bottleneck.
> 
> it is also worthwhile to accelerate the public key ops with MONTMULT
> on the padlock core.  there is assembly optimized code for this in
> openssl 0.9.9 (work in progress).
> 
> the bottleneck for Tor on these CPU's becomes the libz
> compression/decompression overhead with padlock enabled.

My upload speed is much too slow to run into this problem, but could the
compression be (partially) disabled for middle nodes? I'm assuming that
the data they are relaying has already been compressed + encrypted, so
it wouldn't compress much anyway.