RE: Instant chats and central servers

["David Schwartz" <davids () webmaster com>]

> On Wed, May 09, 2001 at 10:35:17AM -0700, David Schwartz wrote:

> >       I don't see how that can be. A P3-600 can RC4 encrypt over
> > 60MB/sec in 64 byte blocks. That figure drops to only 45MB/sec in 8
> > byte blocks. This is a slight overstatement because cache
> > effectiveness is increased by repeatedly encrypting the same stream.

> 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 often.

> Don't get me wrong I rather like RC4, I can write it off the top of my
> head in 30 seconds, encrypt data at very high speeds, and it provides a
> good level of security IF implemented correctly. The problem is I don't
> trust it in other people's implementations unless I've double-checked it
> myself, because it's real easy to mess up.

        That's why I use the OpenSSL implementation. I've seen some *very* subtle
bugs in other implementations.

> If you do not have good key exchange mechanisms in place, none of this can
> be accomplished, and as we all know public-key type exchanges suck CPU
> left and right. It may work reasonably well for your company's internal
> server with 100 people, but it probably wouldn't scale to many thousands
> or hundreds of thousands of users on public chat networks very well. If
> you'd like a suggestion on how to give it a shot though, I'd say your best
> bet is Diffie-Hellman where you can pre-generate your primes on the
> server, re-use them, and shift the work of random number generation to the
> individual client. It's not a perfect mutual-exchange, but it puts the
> ball of security back in the court of the connecting client.

        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 PK work.

        But you are 100% right, bad crypto is *much* worse than no crypto.

        DS