[distcc] SSH encryption overhead
aaronl at vitelus.com
Thu Sep 19 04:45:01 GMT 2002
On Thu, Sep 19, 2002 at 01:30:46PM +1000, Martin Pool wrote:
> Naively subtracting the connection overhead from this might indicate
> that we can send the file in 0.05 CPU seconds, which is pretty
Speaking of connection overhead, are you using an optimized OpenSSL?
Debian's openssl package is currently targetted to i386 on ia32,
causing handcoded Pentium assembly to never be used. These
optimizations would speed the ssh connection up significantly. I got a
2x difference on my system with RSA operations, and I've heard that
there is a 7x improvement on modern SPARC systems when appropriate
assembly is used.
I've been involved in a thread on debian-devel to get this fixed in
the Debian package.
> As somebody pointed out recently, port forwarding is not secure,
That was me :)
> If we hold open a connection using a long-running client side process
> then performance might be comparable to port forwarding, but it will
> be more secure.
This is precisely what I am hoping for.
> What I have in mind is that SSH connections will go via a little
> process that listens on a Unix-domain socket in the distcc directory.
> Unix permissions will make sure that program can only be accessed by
> the relevant user. It accepts connections one at a time and forwards
> them across an ssh channel to a server on the other end.
That sounds sane. I was looking for similar functionality in ssh
itself the other day and was disappointed not to find it.
> Using lzo compression of the data first may (or may not) be a
> performance win, by reducing the amount that needs to be compressed
> and hashed.
This would probably be a win on the receiving side, at least.
http://www.oberhumer.com/opensource/lzo/ claims ~20 MB/sec
decompression on a P133, and 40MB/sec would be enough to break even on
my 1100MHz Celeron according to my benchmarks of openssl's blowfish
cipher (assuming a 2:1 compression ratio, which I don't think is
unreasonable on preprocessed C source).
I just tested it on said machine. It compresses about 42MB/sec and
decompresses 120MB/sec. That's a huge win on the receiving side, but I
need 80MB/sec to break even when sending (I'm continuing to assume a
2:1 ratio). So it wouldn't be a win in terms of CPU time, but
considering the fact that my network transport can not handle
42MB/sec, LZO compression would probably be a good idea anyway (it
would get data across the network much faster).
> ssh -v for these machines seems to show that it is using
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
I think blowfish would be a better choice of cipher. AES is arguably
weaker in light of recent cryptanalysis, and OpenSSL provides an
assembly-optimized implementation of blowfish (which I believe is used
by OpenSSH). AES is implemented by rijndael.c in the OpenSSH
distribution and does not seem to be optimized below the C level.
> I don't want to get into doing half-hearted security. If nothing else
> it will greatly increase the distcc maintenance burden, by making it a
> possible point of security compromise. If instead it depends on the
> transport being secure (either an isolated lan, or ssh), then things
> are much simpler.
> If the source goes across a hostile network without integrity checks,
> then people might try tricks like
> #include "/etc/passwd"
I completely agree about this. This is why I said in my mail that I
thought a method involving an unverified cleartext datastream on a
network that we can't trust is a bad idea, and I explained that this
can allow hostile users to insert their own code into the binary you
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/distcc/attachments/20020919/536a8915/attachment.bin
More information about the distcc