QuantumGate Handshake
Once a (TCP/IP, UDP, Bluetooth etc.) connection has been established between two peers, they start communicating using a specific format. The first part of communications between two peers involves the handshake, which can schematically be seen below.
The handshake can be divided into 6 phases which are discussed in more detail below. It's important to note that peers can exchange noise messages with each other while the handshake is in progress, and even before the handshake begins, in order to confuse eavesdroppers and make traffic analysis more difficult.
During the Meta Exchange phase of the handshake peers exchange protocol version and supported algorithms with each other. The supported algorithms for a QuantumGate instance can be specified using the StartupParameters.
Upon accepting a connection from a peer, the local instance sends the peer a list of the algorithms that it supports. The peer then chooses the algorithms from that list that it also supports and wants to use for this session, and sends the chosen algorithms back to the local instance.
Unless a Global Shared Secret has been specified for both peers (which can be done if you're building your own applications using the QuantumGate library and API), communications during this phase are not yet securely encrypted. QuantumGate does however "encrypt" communications using symmetric keys derived from the Nonce Seed in the Message Transport, and although this is not secure, it simply serves to obfuscate the traffic and make it look random to make traffic analysis more difficult.
Depending on the chosen primary asymmetric algorithm, ephemeral public key(s) is/are exchanged in order to arrive at a shared secret.
Note that up to this point, unless a Global Shared Secret was used, an eavesdropper would be able to read communications between the peers, including the exchanged public key(s).
Once the peers have used the exchanged public key(s) to arrive at a primary shared secret, primary symmetric session keys are derived from the primary shared secret (combined with the Global Shared Secret if used), and the peers begin encrypting communications from this point on using those keys.
Refer to the Key Exchange page for more details about what happens during a key exchange.
Depending on the chosen secondary asymmetric algorithm, ephemeral public key(s) is/are exchanged in order to arrive at a secondary shared secret.
Note that unless an eavesdropper was able to break the asymmetric algorithm used during the primary key exchange, they won't know the public keys being exchanged during this phase because of the encryption using the primary symmetric session keys.
Once the peers have a secondary shared secret, secondary symmetric session keys are derived from the secondary shared secret (combined with the Global Shared Secret if used), and the peers begin encrypting communications from this point on using those keys.
You'll note that the secondary key exchange is similar to the primary key exchange. The purpose of the secondary key exchange is to allow for a second asymmetric algorithm to be used, preferably one that is quantum-resistant.
To find out the secondary symmetric session keys being used, an attacker would first have to break the primary asymmetric algorithm, and then proceed to break the secondary asymmetric algorithm in order to get to the secondary symmetric session keys.
Once the secondary symmetric session keys are available to be used, the peers stop using the primary symmetric session keys for encrypting new messages. The primary symmetric session keys can still be used for a brief period to decrypt messages that were still in transit and encrypted using those keys.
Refer to the Key Exchange page for more details about what happens during a key exchange.
When we arrive at this stage of the handshake, communications are encrypted using the secondary symmetric session keys derived during the previous phase.
During this phase peers will identify and authenticate each other. This is only required when one of the peers is configured to only accept connections from peers that have successfully authenticated themselves (via RequireAuthentication in the StartupParameters).
Even if this is not required, authenticating a connection to a peer gives much more confidence that the connection is secure, and these connections may be preferred above other connections where the peers were not authenticated. For example, a developer of an extender may only choose to work with connections to peers that have been authenticated if they so desire. Other extenders installed on the same instance may not have those requirements and choose to work with both authenticated and unauthenticated connections. It's possible to obtain information about a peer through the QuantumGate::Extender::GetPeerDetails function to find out the properties of the connection to the peer.
For two peers to authenticate each other, they will need to know each other's PeerUUIDs (Universally Unique Identifier) and associated public keys in advance, and those will need to have been added via the AddPeer member function of the Access Manager.
To authenticate each other, peers share each other's PeerUUIDs and a unique Session ID for each peer. These get combined with the ephemeral public keys and shared secrets derived from the previous two key exchange phases, and are signed by the private keys which are associated with their PeerUUIDs. They use each other's public keys associated with their PeerUUIDs to verify the signatures. Once that is done successfully, the peers have identified and authenticated each other.
It's possible for only one peer to authenticate itself to the other if the peer itself doesn't require authentication.
If at least one of the peers is not authenticated, and unless a Global Shared Secret is being used which is known only to them, then the connection between those peers might be vulnerable to Man In The Middle (MITM) attacks.
During this phase peers initialize the session. More information is exchanged, such as the UUIDs of the extenders that they have running.
After the session has been initialized, the handshake transits into the final phase where normal communication can begin. It's during this phase when the extenders running at each peer are notified of a new peer having been connected, and the extenders are then able to start communicating with that peer.
Communications by extenders running on both peers is multiplexed over the same connection.
The symmetric session keys derived during the above described Secondary Key Exchange phase are periodically updated using the key update procedure during the lifetime of the connection.
It's important to note that each extender may additionally implement its own handshake which can be initiated once it gets notification of a peer having been connected. Such a handshake may involve another layer of encryption and/or authentication. However, this is not required by QuantumGate.