[linux-audio-user] Encrypted remote X11 app (Was Unencrypted remote X11 app, Was: headless audio apps)

Malcolm Baldridge linux-audio at paypc.com
Sat Jul 31 23:41:13 EDT 2004

> I'm coming in late to the conversation, but I absolutely agree that
> while it's easier and more secure to remotely display X audio apps over
> ssh, the processing power is often unacceptably high.

OK, my apologies for needlessly confusing the mess.

Not all crypto algorithms are the same cost.  Blowfish is perhaps the
lightest-weight crypto method, with 3DES, IDEA, and CAST (pure-C/shared-lib
version) being the most expensive.

Careful selection of the crypto method can make a big difference. Also, try
explicitly disabling compression.  That may induce too much latency delays
in screen updates.  The reverse may also be true, i.e., things may improve
if you have mild (compressionlevel =3 or 4) compression enabled.

Also, some of the crypto cores in OpenSSL only have non-PIC assembler
implementations, so you'll get 30-50% faster crypto speeds on CAST for
example if you build both OpenSSL and OpenSSH statically.

Just as a cpu cost comparison (Pentium 4, gcc-3.3, OpenSSL 0.9.7d-static):

rc5 (may not be available to SSH)
rc4 (may not be available to SSH)
blowfish/aes-128 (neck-and-neck, though bf is a wee bit faster)
cast (this falls to 3DES if using the shared-lib version)

NOTE!  To get the asm CAST core built into your OpenSSL library, you have to
pass no-shared to the configure option when building it.  What I do is
configure it with shared, build, test, and install OpenSSL, and then "make
clean", re-configure WITHOUT static, build it, and then manually install
libssl.a and libcrypto.a into my /usr/lib

It seems that OpenSSL builds even the "static" library with PIC when you
configure OpenSSL to build "with shared libs" as a time-saving measure -
this causes the build system to pick the Pure C version only.

One other point: most SSL-using services on Linux are NOT threaded, so you
might gain a few % points by building non-threaded SSL libraries.  I don't
think this is probably worth that much, but for the bleeding edgers,
multi-threaded code DOES come with some performance penalties if you're not
using it in a threaded application.

Good luck,

A focus on Quality.

More information about the Linux-audio-user mailing list