mailing list archives
RE: Instant chats and central servers
From: "Richard A. Steenbergen" <ras () e-gerbil net>
Date: Wed, 9 May 2001 16:11:13 -0400 (EDT)
On Wed, 9 May 2001, David Schwartz wrote:
What crack are you smoking? RC4 is a stream cipher, it does not get
applied to block sizes of any kind. Perhaps this shows the performance of
the surrounding components feeding data to be encrypted in someone's
benchmark, but it does not relate to the algorithm itself. Stream ciphers
are just stateful pseudo random number generator, with the results being
XOR'd into the plaintext on a byte by byte basis. This makes them
extremely fast and light weight, but as WEP has recently demonstrated for
us very vulnerable to "attack of the poorly implemented crypto".
Perhaps I wasn't clear. The figures I presented reflect the fact
that when you add encryption, much of the cost of the
encryption/decryption is the overhead of entering and exiting the
decryption algorithm. Since IRC typically results in chunks of about
64 bytes, it's important to test using chunks of that size.
For example, if you use OpenSSL and type 'openssl speed rc4', it
will test with variable sized 'blocks'. Performance will be less with
smaller blocks simply because you have to enter and exit a loop more
Well sure if you make function calls a few million times more you'll see
some impact in performance. That has nothing to do with the crypto, that's
just the performance impact of writing non-inlined functions in C. I just
benchmarked 106MB/s on a p3 1GHz but that only shows performance of a
little addition, modulus, XOR, and changing 2 numbers in a state array.
Anyways, I personally doubt any existing IRC server could even come close
to pushing enough traffic to reach a bottleneck due to cpu use of a
private key cipher for a dozen others reasons.
Actually, there are lots of simple ways to do this. What
ConferenceRoom does, for example, is have the chat server generate a
random key/ID pair (using a cryptographically strong RNG of course).
The key and ID are sent to the client using a secure web server. When
the client connects back to the chat server, he passes his ID, and
begins using blowfish encryption with the key. This way, the chat
client can authenticate the web server (since its SSL key is signed),
and neither the chat server nor the chat client need to do any complex
And then your bottleneck it in the SSL web server. Again, this works fine
for your product, or for at most a few hundred people using an internal
office chat server, but not for hundreds of thousands of people using
large connected chat infrastructures. To quote Vijay, "It does not scale".
But at any rate, this is becoming as off-topic as requests for an ISDN
provider in Detriot, though I can only hope it's slightly more interesting
then trying to figure out the correct way to bitch at people in foreign
Richard A Steenbergen <ras () e-gerbil net> http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)