Encryption

Encryption

Classes for data encryption, mainly used in the GameFile system to encrypt files.

The AesEncryptor Class

This class is the built in implementation of an aes encryptor that converts between a string (usually json, but can be any string) to a byte array for file security.

Implementing the AesEncryptor

The most simple way to use the AesEncryptor is to reference Encryption.DefaultEncryptor. This is a built in encryptor that uses a constant key and initial value. Since these are constant however, it is very prone to being decrypted if your user knows this package is being used. Therefore you are encouraged to either initialize your own AesEncryptor instance or utilize your own encryption (see below).

To initialize your own AesEncryptor instance use the syntax new AesEncryptor(key, initialValue).

Custom Encryptors - The Encryptor Class

This abstract class contains 2 abstract classes to override: byte[] Encrypt(string message) and string Decrypt(byte[] message). Overriding this class allows you to create your own implementation of encryption. Reasons to do so are: your data requires a different encryption method, there is an issue with the native AesEncryptor (which if there is please open an issue!).

Things to Beware Of

Beware that just because you use an encryption method in your application does not guarantee users will never access your unencrypted data. After all this code is being entirely run on their system.

• Examples:
  • If you are building your application using Mono scripting: a good portion of your unity codebase is accessible on the users computers using a decompiler.
  • Even using the ahead of time compiler IL2CPP doesn't guarantee the data can't be inspected when it is in the memory of the application at runtime using specialized programs.
  • Furthermore, if you are using the DefaultEncryptor then you are especially vulnerable to reverse engineering since this package is open source exposing the methodology and keys being used.

Opinion - Why use Encryption at all?

Well even if the encryption is susceptible to reverse engineering for the reasons above it can still be important to use one since it is not ideal to go to the other extreme where any user can manipulate the raw data of the saved data. This can lead to scenarios where users accidentally corrupt their save file by invalidating the syntax or inputting invalid data or users cheat themselves out of the application's intended purpose.

You, the designer, ultimately determine what files needs what level of security. However, in my experience the following are how I would approach levels of security:

• No Encryption: Settings, preferences, and game data where you don't care about users cheating or where it is even encouraged (i.e Doki Doki Literature Club).
• Local Encryption: Game data where you want to discourage manipulation of the game files in games where cheating defeats/ruins the game experience but isn't important if reverse engineered.
• Server Encryption/Anti-Cheat: Game data that is relevant to other users of the application that, if cheated, could ruin other players experience of the game. Examples are public leaderboards, stats, online experiences, etc.