QuantumGate Message Transport
If you intend to use the QuantumGate library and API to build your own applications and/or extenders you don't need to know the information discussed here to get started as QuantumGate takes care of communications for you. This information is provided for those who want to know more about the inner workings.
QuantumGate uses a TCP/IP connection for communications between peers on the network. Once a TCP/IP connection has been established between two peers, they start communicating using a specific format.
Communication between peers happens by exchanging messages with each other. All messages that are exchanged between peers are bundled together into a Message Transport, which can contain up to around 2MB of data. QuantumGate tries to fill the Message Transport as much as possible with message data from the send buffer for efficiency before sending it to a peer.
The structure of the Message Transport is as follows:
The Message Transport can optionally be preceded by random data. The purpose of this data is:
- to make it difficult for eavesdroppers to know precisely where the outer header of the Message Transport begins, making it more difficult to read its contents and
- to make traffic analysis more difficult because of the random data increasing the difficulty to recognize the protocol being used.
The length of the random data is randomly chosen for every Message Transport being sent. Peers communicate the length of this data to each other through the inner header of the Message Transport for every following Message Transport that they send so that they know what to expect.
The outer header of the Message Transport contains its length as well as a seed to be used as a nonce for this message, as well as an hash based Message Authentication Code (HMAC) of the inner header and message data. It's structure is as follows:
The size of the Message Transport uses only 20 bits of the first 4 bytes, while the remaining bits are random. In addition, the exact position of the 20 useful bits can differ based on the configuration of the local instance. For example, when a GlobalSharedSecret is specified in the StartupParameters, the position of the 20 useful bits will depend on the GlobalSharedSecret that is specified. This makes it difficult for eavesdroppers who managed to find out where the outer header begins, to determine the size of the Message Transport, unless they know the global shared secret. And without knowing the size of the Message Transport, it becomes difficult to read the data it contains, and to know where the next Message Transport begins.
The nonce seed is a unique number used for every Message Transport that is sent, and serves to derive a nonce or initialization vector (IV) for encryption and decryption of the inner header and message data. During the initial phase of the handshake, before the primary symmetric session keys have been derived by both peers, this number is also used to derive a "secret" that can be used to generate keys to encrypt/decrypt the inner header and message data. The purpose of this is to obfuscate the data and make it appear to be random in order to make traffic analysis more difficult. As soon as the primary symmetric session keys have been derived during the handshake, they are used to encrypt the inner header and message data.
The HMAC serves to verify and authenticate the encrypted inner header and message data to make sure they have not been tampered with while being in transit. Before QuantumGate attempts to decrypt the inner header and message data, it first uses the HMAC to verify and authenticate the data using all available symmetric session keys.
The structure of the inner header of the Message Transport is as follows:
The counter is used as a sequence number (0-255) to assist in detecting when there's been tampering with communications between two peers and to prevent replay attacks. If messages have been dropped or added, peers will be able to detect this because they'll know which sequence number to expect next. The start of the sequence number is randomly chosen between 0 and 255 for every session between two peers, is increased with 1 with every Message Transport being sent, and when it reaches 255 it wraps back to 0.
The UNIX-style time is used to verify when the Message Transport has been sent. If QuantumGate detects that a Message Transport is too old or too far into the future it will refuse to accept and further process it. Among other things, this assists in preventing replay attacks. The message AgeTolerance can be configured in the SecurityParameters.
This is the length of the Random Data Prefix for the next Message Transport. QuantumGate saves this length for when it receives the next Message Transport so that it knows how much random data it needs to discard before the outer header begins.
This is the size of the optional random data contained in the inner header. This number can differ with every Message Transport being sent. If this number is equal to zero, there is no optional random data.
This is randomly generated data that serves the purpose of padding the Message Transport in order to hide the length of the contained message(s). QuantumGate simply discards this data.
The messages that are delivered with the Message Transport. There may be multiple messages as QuantumGate will fill the message data space with as much messages as possible for efficiency before sending the Message Transport.