Re: Encryption Protocol for Game Network Traffic
2019-12-18
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
Re: Encryption Protocol for Game Network Traffic For those interested, I just updated my protocol in post 1 to reflect the changes discussed.Kind regards,Philip Bennefall URL: https://forum.audiogames.net/post/486560/#p486560 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
Re: Encryption Protocol for Game Network Traffic @6, no problem! URL: https://forum.audiogames.net/post/486277/#p486277 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
2019-12-17
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
Re: Encryption Protocol for Game Network Traffic @5 I have taken a second, even deeper dive into monocypher and I think I can switch to it without too much trouble. Using the low level primitives is something I would avoid regardless of what library I am using, so that was never my concern. My concern is that I need to know what primitives are used under the hood in case I ever have to reimplement the protocol using a different library down the road.Switching to monocypher is painless, except for the transition to XChaCha20 which I'll get to in a second. Swapping out sha512 for blake2b is a no-brainer, so that didn't require much consideration. As for the key exchange and signing that monocypher implements, it's very close to what I already had in my protocol so all I have to do there is change the hash algorithm and I'm good to go.So now, the IV. For many types of games you are absolutely right that 16 versus 40 bytes per packet makes no difference whatsoever. But for finger twitching games where the server and clients are sending, say, 10 or 20 packets per second, with 8 players per game and lots of games hosted on the same server, it does add up. A lot of network game developers spend countless hours using clever techniques to get their packet sizes down as much as possible - I'm talking bit by bit, not bytes. So I have decided to support both a streaming approach when possible, and fall back to stateless packets when required. So for TCP traffic I can simply use the same trick specified in RFC 7905, where the 64 bit counter is XOR:ed with a static IV which is derived from the shared secret, as that still guarantees a unique IV for every message and the difference between 12 and 24 byte IV's is not even noticeable since it is never transmitted over the whire. So I can actually make the switch to monocypher and maintain my current stateful counter design, which is the same approach used by tls 1.2 and 1.3 with ChaCha20 as the cipher.For stateless messages, such as over a UDP connection, the overhead is unfortunate but cannot really be helped. It does offer the possibility to send messages without keeping track of IV's though, which is obviously a huge plus when packets can get lost and be sent out of order etc.So all in all, I can use my existing protocol with minor modifications (namely the hash algorithm and the application of the counter approach for the 24 byte IV's), and still use monocypher's high level API out of the box.Thanks for the feedback and for making me take a second look into it.Kind regards,Philip Bennefall URL: https://forum.audiogames.net/post/486239/#p486239 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
Re: Encryption Protocol for Game Network Traffic @3-4, I understand now. Thanks for that extensive response! I know that monocipher has been professionally audited, which is why I recommend it. Yes, you'd be using XChaCha20, but if you stick to the high-level interface and not the really low level ones, you shouldn't have to worry about that too much.As for the difference of 16 vs. 40 byte overheads, personally I think this is a nitpicking concern, especially since games are usually hosted on servers with a ton of bandwidth. An alternative you could do to minimize packet size, while using monocypher, is to use compression (though I've heard varying responses with compression, from "do't use compression" to "use compression"). URL: https://forum.audiogames.net/post/486050/#p486050 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
2019-12-16
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
Re: Encryption Protocol for Game Network Traffic Sorry for the double post, but I would like to correct myself. I just double checked and I see that sha512 is indeed used by tls 1.3, but *only* for the RSA certificate signature scheme. The ChaCha20 poly1305 suite uses sha256. So I will either switch to sha256, sha384, sha3, or Blake2b. Thanks!Kind regards,Philip Bennefall URL: https://forum.audiogames.net/post/486034/#p486034 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
2019-12-16
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
Re: Encryption Protocol for Game Network Traffic Sorry for the double post, but I would like to add something. I just double checked and I see that sha512 is indeed used by tls 1.3, but *only* for the RSA certificate signature scheme. The ChaCha20 poly1305 suite uses sha256. So I will either switch to sha256, sha384, sha3, or Blake2b. Thanks!Kind regards,Philip Bennefall URL: https://forum.audiogames.net/post/486034/#p486034 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
2019-12-16
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
Re: Encryption Protocol for Game Network Traffic First, thanks for the response! To address your first point, OpenSSL is not installed by default on Windows, which is my primary operating system. I listed some reasons why I don't want to use OpenSSL in the beginning of the post.As a matter of fact, tls 1.3 uses sha512 as part of the cipher suite which includes x25519. I am not aware of any new attacks on sha512 since 2017 when the RFC was published, so I assume that the people behind tls knew about the ramifications of combining sha512 with x25519 when they made that decision. Nevertheless, it would be trivial to use any other hashing algorithm and I have actually looked into Blake2b, but haven't made my final decision yet. I don't think sha512 is a problem in and of itself, though.Regarding monocypher, it is not written by a cryptographer either from what I can tell, but I investigated it very carefully nevertheless. It looks quite good, but my one concern is that it doesn't seem to support the IV/counter construct which is used by tls 1.3. The counter/IV approach makes it really convenient to send sequential messages. If I switch to XChacha20 instead, I will be using a 192 bit IV instead of a 96 bit one, and if I cannot do the counter approach I would have to send 24 bytes for every message. That would bring the overhead of each message from 16 to 40 bytes, which is far from ideal. The 16 byte overhead comes from the poly1305 tag, and right now I don't need to send neither the IV nor the counter over the network as they can be calculated by both parties based on the initial output from the key derivation function.I do care about the overhead because I want to reduce network traffic as much as possible. For a single connection this is not a very big problem, but if a server is hosting a lot of games simultaneously it would quickly add up if packets are sent frequently.I hope this reasoning makes sense. Thanks again for the feedback!Kind regards,Philip BennefallP.S. I did post an earlier draft of the protocol to the cryptography section of Stack Exchange, but it was considered off topic because it was too closely tied to my particular use case. I have tried to make it resemble tls 1.3 rather closely though, so unless I have made some obvious mistake, I think it should be reasonably good. URL: https://forum.audiogames.net/post/486030/#p486030 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
2019-12-16
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
Re: Encryption Protocol for Game Network Traffic First, thanks for the response! To address your first point, OpenSSL is not installed by default on Windows, which is my primary operating system. I listed some reasons why I don't want to use OpenSSL in the beginning of the post.As a matter of fact, tls 1.3 uses sha512 as part of the cipher suite which includes x25519. I am not aware of any new attacks on sha512 since 2018 when the RFC was published, so I assume that the people behind tls knew about the ramifications of combining sha512 with x25519 when they made that decision. Nevertheless, it would be trivial to use any other hashing algorithm and I have actually looked into Blake2b, but haven't made my final decision yet. I don't think sha512 is a problem in and of itself, though.Regarding monocypher, it is not written by a cryptographer either from what I can tell, but I investigated it very carefully nevertheless. It looks quite good, but my one concern is that it doesn't seem to support the IV/counter construct which is used by tls 1.3. The counter/IV approach makes it really convenient to send sequential messages. If I switch to XChacha20 instead, I will be using a 192 bit IV instead of a 96 bit one, and if I cannot do the counter approach I would have to send 24 bytes for every message. That would bring the overhead of each message from 16 to 40 bytes, which is far from ideal. The 16 byte overhead comes from the poly1305 tag, and right now I don't need to send neither the IV nor the counter over the network as they can be calculated by both parties based on the initial output from the key derivation function.I do care about the overhead because I want to reduce network traffic as much as possible. For a single connection this is not a very big problem, but if a server is hosting a lot of games simultaneously it would quickly add up if packets are sent frequently.I hope this reasoning makes sense. Thanks again for the feedback!Kind regards,Philip BennefallP.S. I did post an earlier draft of the protocol to the cryptography section of Stack Exchange, but it was considered off topic because it was too closely tied to my particular use case. I have tried to make it resemble tls 1.3 rather closely though, so unless I have made some obvious mistake, I think it should be reasonably good. URL: https://forum.audiogames.net/post/486030/#p486030 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
Re: Encryption Protocol for Game Network Traffic This is a nice idea, but are you sure it is actually secure? Yes, misusing cryptographic primitives can ruin the security of an application or network completely, but rolling your own crypto is also a terrible idea unless you know what your doing. If you want a portable cryptographic system, use something like Monocypher.I'm not sure why you'd care about the overhead of TLS (unless your talking about DTLS). I'm also not sure why depending on OpenSSL is such a bad thing when its present in literally every Linux distribution imaginable (and even available for literally every other platform out there). I'd strongly recommend that you verify this on the Cryptography stack exchange to ensure that you haven't broken the very thing you are attempting to secure. Also, I'd recommend you use SHA384 and not SHA512 since its vulnerable to length extension attacks; or use another algorithm like Blake2B. URL: https://forum.audiogames.net/post/486000/#p486000 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Encryption Protocol for Game Network Traffic
Re: Encryption Protocol for Game Network Traffic This is a nice idea, but are you sure it is actually secure? Yes, misusing cryptographic primitives can ruin the security of an application or network completely, but rolling your own crypto is also a terrible idea unless you know what your doing. If you want a portable cryptographic system, use something like Monocypher.I'm not sure why you'd care about the overhead of TLS (unless your talking about DTLS). I'm also not sure why depending on OpenSSL is such a bad thing when its present in literally every Linux distribution imaginable (and even available for literally every other platform out there). I'd strongly recommend that you verify this on the Cryptography stack exchange to ensure that you haven't broken the very thing you are attempting to secure. URL: https://forum.audiogames.net/post/486000/#p486000 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Encryption Protocol for Game Network Traffic
2019-12-16
Thread
AudioGames . net Forum — Developers room : philip_bennefall via Audiogames-reflector
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 ProtocolUpon 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
