Home page logo

nanog logo nanog mailing list archives

RE: Instant chats and central servers
From: "David Schwartz" <davids () webmaster com>
Date: Wed, 9 May 2001 12:48:56 -0700

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]