[Tor-BSD] high-bandwidth relays

[Michael McConville]

You mentioned that this was for FreeBSD, but I'd thought I'd address it
in the context of OpenBSD for those interested.

On Mon, Jun 29, 2015 at 07:33:47PM +0200, Christian Sturm wrote:
> On 06/29/2015 07:26 PM, George Rosamond wrote:
> > The question I have is running multiple Tor instances.  At what
> > point is it necessary?
> 
> I'd do that incrementally. Just set up your Tor relay and wait for one
> CPU to be exhausted.

With a weak CPU (Intel Atom D2700), I've actually seen my exit relay hit
a traffic ceiling without coming close to maxing out a CPU core or the
available bandwidth. With the amount of random access pressure that it
puts on both Tor and PF, I wouldn't be surprised if it were
cache-related.

> Also make sure to turn on AES-NI and use a self-compiled OpenSSL to
> speed up encryption. The first one is for AES of course, the other to
> use the optimized ECC code. The OpenSSL version in base doesn't have
> that enabled yet.

Self-compiling OpenSSL/LibreSSL is definitely not suggested or supported
on OpenBSD. Self-compiling (especially for the sake optimization, and
especially in security-critical situations) is generally considered
taboo in the OpenBSD community.

The reason that 128-bit accelerated ECC isn't supported is that the
128-bit arithmetic in the system compiler is buggy. Here's the warning:

> Tor[6677]: We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or
> later, but with a version of OpenSSL that apparently lacks accelerated
> support for the NIST P-224 and P-256 groups. Building openssl with
> such support (using the enable-ec_nistp_64_gcc_128 option when
> configuring it) would make ECDH much faster.

And the relevant email:

	https://marc.info/?l=openbsd-misc&m=142014109006432&w=2

Using GCC 4.9 from ports would likely fix that, but the point about not
self-compiling still holds.