Network Encryption

This page aims to explain the current two cryptation algorithms known to be used by M2 for encrypting and decrypting network data.
Keys are reported as two 64-bit integers (first number, second number) in hexadecimal.
NOTE: The encryption will start after a Phase packet once the Handshake is finished, therefore both the first Phase packet and the Handshake packets are not encrypted.

XTEA Encryption

This encryption is divided in two phases, Auth Phase and Game Phase.

Every packet that uses this encryption gets encrypted and decrypted with the TEA algorithm and a TEA key.

This encryption was used starting from 2004 to 2011/2013. (Before revision 34k was introduced)

The encryption works by having two XTEA keys, the first one (Referred as Auth phase key) is a static 16 bytes key used in the first stage of the communication, this key will be used until a Client has attempted to log in into a Channel (any core that is not an Auth one) with the login key method. Once the client sends a Login packet to a channel, it will also send it's encryptation keys where the server's encryptation keys will be computed. The keys will be changed IMMEDIATLY, no extra packet or data is needed to change the keys. This generated second keys are referred as Game phase keys.

The client computes it's decryptation key (likewise, the server computes it's encryptation key) by performing an XTEA of the encryptation key (decryptation key for the server) with a Special key.

Key list

Special keys

The Special key was generated by the Client and the Server during the login into the Game core, it is known that in very old version of M2 (such as the Korean 2003 beta) the following hardcoded key might be used rather than a random generated one.

Diffie-Hellman key exchange

The improved packet cryptation is performed by choosing a suitable cipher based from the shared secret that is exchanged with Diffie-Hellman.
This encryption is used from 2011/2013 to today.
NOTE: The handshake phase is not encrypted.

Unified Diffie-Hellman key exchange

1. Initialize RFC 5114's 1024-bit MODP standarized parameters (p, g, q)
2. Randomly generate a Static and Ephemeral public and private keys with Unified Diffie-Hellman.
3. Pass the shared secret length and public keys to the network and perform an agreement with the received public keys and shared secret length.

Cipher choose

1. Takes the remained of the first byte in the shared secret block with the shared secret size. This number will determine where the first cipher number that is stored in the shared secret block.
2. Takes the remained of the second byte in the shared secret block with the shared secret size. This number will determine where the second cipher number that is stored in the shared secret block.
3. Takes the remained of this two bytes generated from the secret block with the max algorithms supported and pick an algorithm.
4. The shared secret block contain the algorithm's keys and a block data (a random block is being used because some algorithms do not support IV), that will be used to crypt the packets.
5. The selected cipher will be processed with CTR Mode and the generated IV
6. If the keys are generated by the server, the first cipher will be the encryptation cipher. the second will be the decryptation cipher. The keys are inverted in client side.

(The lengths are the default lengths assigned to the algorithm)

Appendix

Secret block content:

Start of shared data
first key
second key
non important data
second IV
first IV
End of shared data

List of known algorithms:

• RC6
• MARS
• Twofish
• Serpent
• CAST256
• IDEA
• DES-EDE2 (Triple DES)
• Camellia
• SEED
• RC5
• Blowfish
• TEA
• SHACAL2