I'm writing my first login system for a game. Decided on SRP and have successfully implemented that interaction. The client and server have the same session keys now. How do I use them?
All the info about it says that it can be used for encrypted communication, but I haven't found one that says how.
SRP exchanges a session key in the process of authentication. This key can be used to encrypt the user's login session...
http://srp.stanford.edu/advantages.html
The established session key ‘S’ can be used to encrypt further communication between client and server.
http://connect2id.com/products/nimbus-srp
What are the options here, and what are the good options? AES?
Thank you!
I would not recommend that you use SRP to login and then to do the data transport encryption yourself with the shared SRP session key. It would be safer and easier to use regular TSL using out-of-the-box libraries and well documented configurations (e.g. self signed certificates). Then over the top of that encrypted connection login the user in with SRP as a password proof and you are done.
If you really want to do what you suggest then the symmetric encryption algorithm you choose would be based on performance overhead verses known strengths/weaknesses of the algorithm. AES is very strong but very expensive. If you were encrypting files on disk you wanted to keep safe you want to use a very strong cypher. Game traffic is rarely going to need to be protected against extended offline attack; typically the results of the game are public and a trace of the game decrypted hours after the game ended has no value. In which case you could use an very cheap stream cypher to protect the traffic.
By way of example you could consider ISAAC which is so fast and cheap it is also used as a random number generator. This means you can find implementations in just about every language include browser javascript. You would seed the initial state of an Isaac generator at both client and server using the SRP shared key. Then for each 32 bits of data you want to transmit you take the next Isaac 32 bit pseudo random and XOR the data and send that. At the other end you XOR with the next Isaac 32 bit pseudo random to recover the original data. Anyone snooping the packets doesn't have the Isaac seed which came from the SRP shared key so they cannot decode the scrambled data. Isaac needs 256 x 32bit words as its initial state and the SRP key would only be 8 x 32bit words (if you used SHA256 as the SRP hashing algorithm). This implies you need to either stretch your SRP key else repeat it 32 times to make the Isaac seed. A key stretching algorithm such as PBKDF2 could be applied to expand the SRP key to fill the initial Isaac table. That should be "good enough" to protect a game from "real time" snooping. (Edit: Recursively hashing the key 32 times to generate the isaac seed is another idea.)
Once again I would not advise the above approach; I would recommend using standard TLS/HTTPS to encrypt the connections then use SRP as a password proof to authenticate the user only and send all traffic over the initial encrypted connection.
(Edit There is an assignment on an introduction to cryptography course to break a Vigenère cipher like the one above using the probabilities of each letter appearing in a large enough body of encrypted text. So you should compress the data you are sending before encrypting it. Yet really what this tells us is "never write your own encryption" as you may have missed a possible attack only use professionally peer reviewed code such as TSL.)