|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Instant chats and central servers
On Wed, 9 May 2001, David Schwartz wrote: > > 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. Well sure if you make function calls a few million times more you'll see some impact in performance. That has nothing to do with the crypto, that's just the performance impact of writing non-inlined functions in C. I just benchmarked 106MB/s on a p3 1GHz but that only shows performance of a little addition, modulus, XOR, and changing 2 numbers in a state array. Anyways, I personally doubt any existing IRC server could even come close to pushing enough traffic to reach a bottleneck due to cpu use of a private key cipher for a dozen others reasons. > 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. And then your bottleneck it in the SSL web server. Again, this works fine for your product, or for at most a few hundred people using an internal office chat server, but not for hundreds of thousands of people using large connected chat infrastructures. To quote Vijay, "It does not scale". But at any rate, this is becoming as off-topic as requests for an ISDN provider in Detriot, though I can only hope it's slightly more interesting then trying to figure out the correct way to bitch at people in foreign countries. :P -- Richard A Steenbergen <[email protected]> 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)
|