Encryptions comparison
From VbGORE Visual Basic Online RPG Engine
Contents |
[edit] What is encryption?
Encryption is the process of altering the content of data to make it harder to read by others. Encryptions are used in games to prevent the client from being able to access information that they shouldn't be looking at in the first place.
Encryption can be handled in a variety of ways from simple value replacements and bit shifts to very complex algorithms that can take years to decrypt.
[edit] Encryption in vbGORE
Encryption is used in vbGORE, by default, only in the packets. This doesn't mean, though, that this is the only place you should use it. Encryption works great from hiding any kind of information from the user. You can use it to keep your graphics, sounds and music safer from being stolen by encrypting the appropriate files. You can also encrypt unaltered vbGORE files, such as the *.map files, to prevent people from peaking into the maps.
Encryption on the packets is used to prevent packet manipulation and more importantly, packet replaying. Packet manipulation is done by finding how packets are written, and to alter the data in the packet to get results you want. Although vbGORE's server checks most all of the packets the user sends and checks if they are valid, in a poorly designed game a user could tell the server anything they could want. Another is packet replaying, which is taking a packet sent and sending it over and over. This is common for doing events very fast that are often limited by the client, such as attacking.
vbGORE prevents packet replaying and manipulation by using a series of unique keys that it cycles through so each packet, even if it has the exact same data and uses the exact same encryption, contains different data when encrypted. Because the server tries to decrypt the data, if the data is encrypted incorrectly, the server will decrypt the data incorrectly and end up just discarding it because it is so corrupted.
[edit] Encryption algorithms used
I am not as knowledgeable about encryption as I am about compression, so the details on the encryptions I can not provide as well, such as which encryptions are harder to break than others from anything more than educated guesses.
- XOR
- XOR encryption is a very basic, quick encryption revolving around the Exclusive OR operator. The encryption is quite weak, and is reversed by simply replaying the algorithm through the same key. XOR can be decrypted through a Known Plain-text Attack, but this isn't very common among the files of vbGORE, and more of a concern on text-based documents.
- RC4
- RC4, or ARCFOUR encryption, is one of the most commonly used encryptions on streams of data. One example of the RC4 implementation is SSL encryption on HTTPS:\\ websites or WEP keys on wireless internet connections. It has proved useful at many times, one being because of its speed, but it is still crackable by a knowledge hacker.
- GOST
- GOST is the Soviet Union's variation of DES encryption.
- Skipjack
- No information is provided at this time.
- Blowfish
- Blowfish was developed in 1993, though isn't used as commonly because of its smaller block size, which was changed in the variation, Twofish.
- Twofish
- Twofish takes the cake on one of the greater algorithms available in vbGORE.
- CryptAPI
- CryptAPI is an API call to a library provided by Microsoft for cryptography.
[edit] Benchmarks
The following benchmarks are performed on an Intel T1300 1.66Ghz processor with 502MB of RAM laptop. All encryption and decryption was done with the File Processor tool of vbGORE in compiled mode.
The files compressed were most all the files required by the client in the v0.5.2 release. This consisted of 222 files totaling at 12,098,898 bytes in size. All files were encrypted individually. All encryptions used the key "This is my test key !@#123".
- Size is represented in percentage of original size, so 20% means that the compressed size is OriginalSize * 0.2 bytes
- All times are presented in seconds
- Strength is measured by articles written on the algorithm on how powerful it is, and is a rough approximation on strength in comparison against the other algorithms used, with a measurement between Weak, Average and Strong
| Encrypt Speed | Decrypt Speed | Size | Strength | |
| XOR | 0.56 | 0.60 | 100.00% | Weak |
| RC4 | 0.66 | 0.62 | 100.00% | Weak |
| GOST | 16.55 | 16.86 | 103.33% | Average |
| Skipjack | 7.87 | 8.05 | 103.33% | Average |
| Blowfish | 13.05 | 12.87 | 100.03% | Strong |
| Twofish | 17.49 | 17.39 | 101.81% | Strong |
| CryptAPI | 1.6 | 1.45 | 101.77% | ??? |
[edit] Which algorithm to use?
With encryption, the answer is not so clear as it is with compression. Not only are the benchmarks needed to take into consideration, but the strength of the encryption which can be very hard to compare.
First off is packets. This is an easy one, because we want pure speed and no size inflation, which is going to be either XOR or RC4. Only these two are offered by default for the packet encryption. XOR will be slightly faster, while RC4 will be slightly more secure. Most of the processing time for both of these went to reading and writing to those 222 individual files, so they are going to be very fast.
Now for the hard part - files. First, XOR or RC4 will also work fine for files. If there are some files that you are not too worried about but still want to keep secure, such as sound files, these would be the way to go. When it comes to graphics, though, security becomes a big issue. Graphics are loaded and unloaded into memory quite frequently (sound is, too, but not nearly anywhere as frequent), so you will either have to increase the time they stay in RAM (more RAM usage), or use a weaker algorithm. Twofish would probably be a bit overkill, but would offer the best security. The time it would take to load a graphic file would increase a bit, but not much. I'd recommend Twofish for those who want to encrypt their data files that are only loaded at runtime, though, where speed is not an issue.
For the graphic files, if you don't want to use XOR or RC4, Twofish would work if you increase the time they're in memory, or CryptAPI. I have no idea how powerful CryptAPI's security is - I assume it is around average, but it has got to be better than XOR and RC4 with just slightly more time, so it is a good alternative.
As mentioned earlier, which encryption to use where becomes much more complicated then compression. The key things to look for though are how often the information will need to be encrypted / decrypted. For packets, this is once each for every packet, so time becomes beyond critical here. For graphic files, this can be moderately time critical, but in reality you'll only notice a slight pause, if any, every time you load a new graphic file. For the rest of the files, speed isn't too big of a concern.
Even though this guide isn't so conclusive, hopefully it betters your understanding on which encryption algorithm will be right for you for certain conditions.
