Wildfire 2: Branches

Wildfire 2: Branches

As said in my last post Wildfire 2 needs to support two university projects:

  • The first, a digitization of a board game (in ASGE)
  • The second, a mobile AR game being a cross between Tetris and Bejeweled (in Unity and Vuforia)

The first project needs the server to be integrated into its codebase (with a common library being shared between client and server), and the second game does not- the first project utilises CMake and I don’t have much experience integrating a library into CMake (so it supports Windows, macOS, and Linux), so it may be difficult integrating the CryptoPP library into the project that the server uses for encryption.

Thus the project has effectively split into two branches- the current Visual Studio version of Wildfire 2 will continue to support the mobile AR game exclusively, while the code will be moved across and adapted into the board game. There’s not many differences, the board game uses a different networking library (ENetPP verses SFML’s networking module) and most crucially does not support the advanced encryption techniques that CryptoPP offers (it instead uses the old Wildfire 1’s XOR method).

This effectively means that the Visual Studio version will offer far more secure communication than the one used with the board game… however

RSA 1024 only supports 128 bytes per message!

This was admittedly an oversight of mine that I only found out when implementing the final encryption step in the C# game client for the AR game- the game tried to encrypt its public key for sending but it’s too large to encrypt!
I plan to fix this by splitting-up the message into 128-byte (that is, 128 character) chunks and then sending this message to the server as normal. Obviously this splitting-up of gamedata will have to occur both ways (i.e, on both client and server). I could also increase the encryption level (i.e. using RSA 2048 keys instead of RSA 1024 keys) however the whole purpose of the Wildfire protocol is to get the data to its destination as fast and as securely as possible- increasing the encryption level will cause encryption and decryption to take longer, which is no good for this use case.

The whole point of the encryption & security itself is to provide anti-tamper protection to protect gamedata from being tampered with via a wire analyser tool (such as Wireshark). The element of ensuring data only comes from the real client is important as some AAA games do not implement this properly- Call of Duty Black Ops 2 for example does not check that a “end game” request comes from the real host of the multiplayer match (enabling anyone with a wire analyser to effectively end the game).


No Comments

Add your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.