Re: Trying to get some feedback on this authentication/encryption protocol



On Feb 26, 5:13 pm, g...@xxxxxxxxxxxxx (Greg Rose) wrote:
In article <d8983192-c5b7-4c23-bd09-dff5f74b4...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Christoffer Lerno  <christoffer.le...@xxxxxxxxx> wrote:
On Feb 25, 10:34 pm, kg <kristiag+n...@xxxxxxxxxxxx> wrote:
Christoffer Lerno <christoffer.le...@xxxxxxxxx> wrote:

My experience from profiling poker servers (employing custom
encryption + compression) is that compression is the greatest cost of
a such a server, followed by encryption (I believe it was using TEA).
An action game with server-based physics might be different, but my
game has more in common with the former.

Surprising. But you know your application, I don't.

Not so strange really. If you look at a poker table then the result of
most actions are broadcasted to all players at the table. If the
average number of players are 7 and each action cause at least 1
message to be sent to all those players, it's not difficult to see how
encryption+compression+serialization could account for a huge piece of
the server's CPU cost. Lobby servers are even worse, you can have
10.000 players watching registrations to a tournament with the same
amount of players. That's millions of messages due to registration
updates only in a naive implementation. Obviously we spent a lot of
time reducing this number, but the fact is that game lobbies do little
more than send messages.

In this situation reducing the number of packets and the cost of
sending a single packet suddenly becomes the way to increase capacity
of the server.

Then you really need to be looking at the
processing in your network stack, compared to
which the encryption is negligible.

Well, that depends on how the encryption is implemented doesn't it? A
naive implementation might be quite costly (I've seen this in practice
- not the fault of the algorithm, but how it's applied), if you don't
know what you're doing. I don't know much but I'm trying to
learn... :)

According to OpenSSL, my computer can encrypt ~ 130 megabytes per second,
per core, with AES. TEA might be faster. RC4 is twice(?) as fast as
AES. Hardware AES will be faster(?). Trivium is ~ 300-500 megabytes
per second.

TEA has lots of rounds and isn't very fast. For
the life of me I don't know why people use it.

And there are ways to make it even slower. Like the implementation I
encountered where a random number was used to pad the block. Good idea
in theory perhaps - I don't know how much it helps - but not such a
great an idea if you use a random number generator that takes 10-100
times as long as encrypting a block...

I doubt that my server will be as extreme as the lobby servers I
mentioned when it comes to sensitivity to packet delivery costs, but
it's good to have options if it shows up as a big cost when
serializing data.

A good stream cipher encrypts nearly as fast
as moving the contents of the memory, which
usually happens multiple times in most network
stacks.

That's comforting to know. As you might understand from posts - the
only experience I have of explicit encryption (as opposed to
transparently provided by frameworks) with a sub-par implementation of
TEA.
After we optimized that implementation it still ranked high in the
profiler, had it been - say - 4 times as fast then we wouldn't even
have noticed it.
.



Relevant Pages