-- Jason Slagle - CCNP - CCDP Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin@tacorp.net - jslagle@toledolink.com - WHOIS JS10172 /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . If dreams are like movies then memories X - NO HTML/RTF in e-mail . are films about ghosts.. / \ - NO Word docs in e-mail . - Adam Duritz - Counting Crows On Wed, 9 May 2001, David Schwartz wrote:
No.
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.
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.
Our tests with RC4 seem to indicate different. Maybe we just have a bad implementation of it. Maybe it's time to look at it more.
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.
Nope, and that seperation is planned, but probably not until we do out full rewrite.
I think you're simply assuming that it's infeasible but you haven't actually tried it or done the math. We've done it with ConferenceRoom, and the encryption load is so low as to be almost lost in the noise.
As I said, we can encrypt now between servers (The code is in). Based on the math we saw testing this functionality, it didn't seem feasible to do it to the clients, but as I said, maybe we just had a bad implementaion. :puts it on the list of things to try: Jason