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".
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.
If a chat server with a P3-733 has a throughput of, say, 8MB/sec
out and 3MB/sec in, encryption on all that traffic would eat less than
15% of the CPU. There would be some memory usage to store all the
encryption/decryption state information but memory is cheap.
That's a lot of chat! But the issue isn't really encryption of the bulk
data, even after you throw in good IV's, message authentication codes,
etc. The real issue is key exchange.
If you used a dual processor machine and separated the actual
chat layer from the I/O layer, you could put the encryption in the I/O
layer. This is actually not that terribly hard to hack into Ircd.
Terribly hard to hack, no.
Terrible hack, yes.
PS: If you use public-key encryption to do the initial key
exchange, that can be significant if you have a high rate of
connection establishment. But if you assume that everybody has a
password already known to both them and the chat server, it's not a
problem.
And so unbelievably easy to defeat you might as well not have bothered.
Bad crypto is almost worse then no crypto because it gives you a false
sense of security.
First think about what you're actually wanting to protect with crypto.
Is it the communication between the server and user, so that noone can
intercept (OR inject!) data? It certainly isn't a good thing when someone
can compromise a machine local to you and intercept/inject commands into
your irc session, as many efnet opers seem to have found out. It also
isn't a good thing when you can compromise a machine local to a server,
and intercept/inject commands which can destroy the entire structure of
the chat network. For example, it is easy enough to capture the SJOIN
flood of a server synchronizing to the network (which itself is an archiac
design, but irc is good at those), then hijack the tcp session and play
back that list with slight modifications so that you blast the entire
state database on all servers and do things like deop every channel on the
network, etc. Obviously this is an area where real crypto provides many
benefits.
Is it for end-to-end users across the network, so people can talk
privately without the fear of an unethical server admin (or admins)
snooping on their conversations? Sure it's possible to establish a direct
client to client tcp connection, but that doesn't scale very well for
things like meetings, which IRC would be rather well suited for.
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.
