Ok, way better now. My suggestion is the following (and please note that I'm not an expert in cryptography, just a guy who solved a very similar problem like you have):
-----
1. generate good (pseudo) random numbers (at the client)Forget
rand(). Now. Instantly. Ignore that it ever existed. It's just plain bad for anything involving cryptography.
SFML's
Randomizer::Random uses
rand(). You've been warned.
Here is a list of decent random number generators:
http://en.wikipedia.org/wiki/List_of_pseudorandom_number_generatorsHere is a nice, short paper describing a couple of algorithms:
http://www.lomont.org/Math/Papers/2008/Lomont_PRNG_2008.pdfSeveral libraries already include decent pseudo random number generators, e.x. Boost has Boost.Random.
Linux has /dev/random
Windows has CryptGenRandom
preview for 3. use a random number as key for symmetric encryptionComing later...
2. exchange the random number securelyYou must get your random number securely(!) from the client to the server. You can use asymmetric encryption (public key cryptography) to do that.
One choice would be the Diffie-Hellman key exchange:
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchangeAnother choice would be to use the famous asymmetric encryption algorithm RSA:
http://en.wikipedia.org/wiki/RSAIn that case of RSA you would simply use the OpenSSL command line tool to generate a public key / private key pair. Hardcode the public key in the client code (and give the client to your users) and hardcode the private key in the server (and never, ever give out the server or the private key to anybody). Then you could include the OpenSSL library in both your client and your server to send a piece of encrypted data from the client to the server. This piece of encrypted data includes the aforementioned random number and e.x. login credentials like username and password. On Linux using OpenSSL is simple, on Windows using OpenSSL is a pain in the ass.
Unfortunately most libraries including asymmetric encryption algorithms are huge bloatware - but the topic is a quite difficult one, not to be solved simple.
Please note that asymmetric encryption does a lot of number crunching on the CPU so it's used rarely, e.x. only once during login for each connection, while the rest of the transmission of the connection is done with the way "cheaper" (CPU load wise) symmetric encryption.
3. use a random number as key for symmetric encryptionAfter both the client and the server known your random number -and nobody else does since you transmitted the key securely- you can use that random number as a key for a symmetric encryption (block ciphers).
Like Wikipedia says AES, Blowfish and Twofish are commonly used algorithms which should have plenty implementations flying around. Interesting is the TEA/XTEA family of block ciphers as they are meant to be very small, very simple, very fast but still secure enough. The whole C code for XTEA is on it's Wikipedia page.
-----
Rakknet, another well known UDP based network library, includes a very similar mechanism to what I explained above. The documentation for its so called "secure connections" can be found below, maybe this will help your understanding:
http://www.jenkinssoftware.com/raknet/manual/secureconnections.htmlFinally I want to say that it will take you a lot of time to do it "right". And afterwards you will find out that what you considered "right" has some flaws. And then it will take you even more time to fix the flaws. Sorry if that sounds pessimistic, but I've spent my fair share of time on it and I made my fair share of mistakes. Maybe I just want to encourage you to check your priorities: how important is the encryption currently in comparison with other features of your project?
One way or the other good luck with your efforts!
