[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: aes performance
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: aes performance
- From: coderman <coderman@xxxxxxxxx>
- Date: Mon, 23 Feb 2009 11:09:14 -0800
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Mon, 23 Feb 2009 14:09:17 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=KnOf9n0Scgo7goPQIjXvQrW1/7laJf2DIuZL4Jg2i4E=; b=nYGRSMZk+V2UNKHhpOwrW6XIwT5T5iYOQWi9GyHHedG4816ZzUMEmcPhTIKFxaUjaT 9RpIkLLV/XughhUS79LSGsKL8EEY7roIyFv5xY9DyNr+GDqyakcKGpYDyjxNFnj9Rw7E Xk2d9v7anT2ARdIaNDga/Eabcsvpa14tl09xo=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=izMvtYgJst6XN5iKURjEFuFYWivMod374E5uG1by5vwmbX2nToGZHaiJezKwL8+aZ9 avsX6PBkRn3H/N10R0N32oHuuQuGWnjM2epu8++buERCubGXFZGqIg82tkRWr1cedUve fUu53cWDiuAakrhO1sJnsYqMJ64eFeOJ3hHn8=
- In-reply-to: <49A2CD79.8030602@xxxxxxxxxxxxxxxxxxxxxx>
- References: <49A158AB.2090703@xxxxxxxxxxxx> <49A2CD79.8030602@xxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
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.
> ...
> 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.
best regards,