Implementing a Handshake for a Socket Connection

Question

I'm developing a program with a client/server model where the client logs on to the server, and the server assigns a session id/handshake which the client will use to identify/authorize its subsequent messages to the server.

I'm wondering what length should the handshake be for it to be reasonably secure but also short enough to minimize data overhead, since I'd like to have it be low latency.

I'm thinking of using MD5 or murmurhash2 with the username and a random number salt with a collision detection, but I'm wondering if there's a more efficient solution (i.e. a better algorithm) and whether 32bits is too much/too little for this kind of thing.

Any input is highly appreciated.

Answer 1

Hi,

I would use a HTTPS connection for your client/server communications. It's easy to use (almost all the major SDKs implement it) and it provides good encription.

Regards.

PD: In reference of encryption method I would use Whirlpool because Mr. Rivest said in 2005 it was broken.

Answer 2

This may not be as simple as it looks. Note that if you send anything in clear over the network (e.g. session id/handshake), anyone can eavesdrop the communication and reuse this value to act as the client. If you cannot use https, as the first answer suggested, you probably need to look at key agreement protocols. Once both parties agree on a shared secret key (which cannot be reconstructed based on observed communications), you can use it to authenticate all the remaining transmissions with a MAC (e.g. HMAC).

Whatever you do, don't use MD5, it's so totally broken. Whirlpool may also not be the good option, it's slower and there is a recent (theoretical) attack on the main part of it, see ASIACRYPT 2009 Program. I would stick with SHA-256 for now.