Encryption Protocol for Game Network Traffic
For the last little while, I have been doing research into how to do encryption properly for networked traffic in my future games. I could use OpenSSL/tls and call it a day, but I wanted to roll my own for a few reasons:
1. OpenSSL is a large dependency; I want something much more lightweight.
2. The TLS protocol has more overhead in terms of network traffic than I am willing to put up with.
3. I am not required to interoperate with tls servers, so the compatibility is not necessary.
4. I find the OpenSSL software license too restrictive.
Of course, I did read the tls 1.3 specification and took a lot of ideas from it, as combining cryptography primitives incorrectly can ruin the entire system. SO I am using x25519 for key exchange, ed25519 for the certificate, and the ChaCha20 stream cipher with poly1305 for authenticated encryption.
Here is my protocol for those who are interested. Maybe this will help others who are trying to do something similar. In any case, feedback is welcome!
Blastbay Studios Game Network Protocol
Upon client connect:
* Generate a 32 byte SALT.
* Generate an x25519 public and private key pair.
* Use the x25519 algorithm to derive a shared secret from the newly generated private key and the server's static public key.
* Use HKDF with the SHA512 hashing algorithm to derive 704 bits of keying material, with the SALT that was previously generated.
* Use the first 256 bits to make up a key and the next 96 bits to make up an initialization vector (IV), and initialize a ChaCha poly1305 session with 20 rounds using the IV and a 64 bit counter of 0 as specified by RFC7905. This session will be used to encrypt data that is sent to the server.
* Use the next 256 bits to make up a key and the final 96 bits to make up an initialization vector (IV), and initialize a ChaCha poly1305 session with 20 rounds using the IV and a 64 bit counter of 0 as specified by RFC7905. This session will be used to decrypt data that is received from the server.
* Generate 32 random bytes and encrypt these with the first ChaCha poly1305 session. We call these the challenge.
* Increment the sequence counter of the first ChaCha poly1305 session by 1.
* Generate a packet containing the following data:
1. An eight byte header which represents the name and version of the protocol.
2. The 32 byte SALT.
3. The 32 random challenge bytes that were encrypted by the first ChaCha poly1305 session.
4. The 16 byte tag verifying the integrity of the encrypted challenge bytes.
5. The raw export of the public x25519 key, which is 32 bytes.
* Send the packet over the whire.
When the server receives the connection data described above from the client, it should do the following:
* Verify that the protocol is supported. If there is a mismatch, a plaintext failure packet is sent and the connection is terminated.
* If the protocol is supported, use the x25519 algorithm to derive a shared secret from the server's static private key and the client's public key.
* Use HKDF with the SHA512 hashing algorithm to derive 704 bits of keying material, with the SALT that was received from the client.
* Use the first 256 bits to make up a key and the next 96 bits to make up an initialization vector (IV), and initialize a ChaCha poly1305 session with 20 rounds using the IV and a 64 bit counter of 0 as specified by RFC7905. This session will be used to decrypt data that is received from the client.
* Use the next 256 bits to make up a key and the final 96 bits to make up an initialization vector (IV), and initialize a ChaCha poly1305 session with 20 rounds using the IV and a 64 bit counter of 0 as specified by RFC7905. This session will be used to encrypt data that is sent to the client.
* Use the first ChaCha poly1305 session to decrypt the 32 random challendge bytes received from the client.
* Verify that the tag matches.
* Use ED25519 to sign the 32 random challenge bytes using the server's static private key (this produces a signature which is 64 bytes in length).
* Use the second ChaCha poly1305 session to encrypt the 32 random challenge bytes that were previously decrypted, as well as the 64 byte signature.
* Send the encrypted result which will be 96 bytes, plus the 16 byte tag over the whire.
* Increment the sequence counters for both ChaCha poly1305 sessions by 1.
When the client receives the response from the server, it must do the following:
* Decrypt the data using the second ChaCha poly1305 session.
* Verify that the tag matches.
* Increment the sequence counter of the second ChaCha poly1305 session by 1.
* Verify that the 32 random challenge bytes are the same as the ones sent to the server in the first step.
* Use ED25519 to verify the message signature using the server's static public key.
* If the verification succeeds, the handshake is concluded and the two ChaCha sessions can then be used to securely transmit application data.
At the end of the handshake, the sequence counter for both sessions should be 1 for both the client and the server.
Whenever a packet is encrypted or decrypted, the corresponding sequence counter for the given session should always be incremented by 1.
Each packet will contain the ciphertext plus the 16 byte tag. This tag must always be verified by the receiver.
Philip Bennefall
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
