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". 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. -- 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)