QuantumGate Key Exchange
Key exchanges are always initiated by the peer that has accepted an incoming connection from another peer. This happens during the initial stages of the connection during the handshake, and throughout the lifetime of the connection through the key update procedure.
QuantumGate always does key exchanges in pairs (a primary and a secondary key exchange), preferably using different asymmetric algorithms. This is to provide an additional guarantee for security if one of the algorithms is compromised. It's recommended to use a traditional asymmetric algorithm for the primary key exchange and a quantum-resistant asymmetric algorithm for the secondary key exchange.
When you're building your own applications using the QuantumGate API, you can specify the algorithms you want to use and support via the StartupParameters.
QuantumGate uses two types of key exchanges depending on the chosen asymmetric algorithms:
The Diffie-Hellman key exchange used by QuantumGate can be seen schematically below.
Assuming that the algorithms that will be used have already been exchanged and agreed upon, the following steps are performed during this key exchange:
| Step | Action |
|---|---|
| 1 | The peers generate unique ephemeral key-pairs for the chosen asymmetric algorithm using a key generation function. These key-pairs will only be used during this key exchange. |
| 2 | Each peer sends the public key from its asymmetric key-pair to the other peer. |
| 3 | Each peer receives the public key from the other peer. |
| 4 | Each peer uses its asymmetric key-pair together with the received public key from the other peer in a Diffie-Hellman function to derive a shared secret, which will be identical for both peers. |
| 5 | Each peer combines the shared secret with a global shared secret (if used) known to both of them, and uses a Hash-based Key Derivation Function (HKDF) to generate random bytes to be used as keys. |
| 6 | Each peer divides the random bytes generated in the previous step into 4 ephemeral keys, which are grouped into two pairs: Symmetric encryption key-pair: - An encryption key to be used with the chosen symmetric algorithm. This key is used to encrypt messages before sending them to the other peer. - An authentication key to be used with the chosen hashing algorithm to generate Hash-based Message Authentication Codes (HMACs) for the encrypted messages before sending them. Symmetric decryption key-pair: - A decryption key to be used with the chosen symmetric algorithm. This key is used to decrypt messages received from the other peer. - An authentication key to be used with the chosen hashing algorithm to verify the Hash-based Message Authentication Codes (HMACs) for the received messages before decrypting them. The length in bytes of the encryption and decryption keys depend on the chosen symmetric algorithm, while the length of the authentication keys are 64 bytes each. Note in the above image that the same bytes chosen as the encryption key by the remote instance are chosen as the decryption key by the local instance. Similarly, the bytes chosen as the decryption key by the remote instance are chosen as the encryption key by the local instance. |
The key encapsulation key exchange used by QuantumGate can be seen schematically below.
Assuming that the algorithms that will be used have already been exchanged and agreed upon, the following steps are performed during this key exchange:
| Step | Action |
|---|---|
| 1 | The local instance generates a unique ephemeral key-pair for the chosen asymmetric algorithm using a key generation function. This key-pair will only be used during this key exchange. The remote instance uses a random generator to generate a secret that will be used later to derive the session key. |
| 2 | The local instance sends the public key from its asymmetric key-pair to the remote instance. |
| 3 | The remote instance receives the public key from the local instance. |
| 4 | The remote instance uses the public key from the local instance to encrypt the generated secret. |
| 5 | The remote instance sends the encrypted secret to the local instance. |
| 6 | The local instance receives the encrypted secret from the remote instance. |
| 7 | The local instance uses the private key from its asymmetric key-pair to decrypt the encrypted secret. Both peers now share the same secret. |
| 8 | Each peer combines the shared secret with a global shared secret (if used) known to both of them, and uses a Hash-based Key Derivation Function (HKDF) to generate random bytes to be used as keys. |
| 9 | Each peer divides the random bytes generated in the previous step into 4 ephemeral keys, which are grouped into two pairs: Symmetric encryption key-pair: - An encryption key to be used with the chosen symmetric algorithm. This key is used to encrypt messages before sending them to the other peer. - An authentication key to be used with the chosen hashing algorithm to generate Hash-based Message Authentication Codes (HMACs) for the encrypted messages before sending them. Symmetric decryption key-pair: - A decryption key to be used with the chosen symmetric algorithm. This key is used to decrypt messages received from the other peer. - An authentication key to be used with the chosen hashing algorithm to verify the Hash-based Message Authentication Codes (HMACs) for the received messages before decrypting them. The length in bytes of the encryption and decryption keys depend on the chosen symmetric algorithm, while the length of the authentication keys are 64 bytes each. Note in the above image that the same bytes chosen as the encryption key by the remote instance are chosen as the decryption key by the local instance. Similarly, the bytes chosen as the decryption key by the remote instance are chosen as the encryption key by the local instance. |
The 2 derived symmetric key-pairs for encryption and decryption are together referred to as the session key. The session key is added to an internal list of session keys maintained by the QuantumGate instance for that specific connection, and is used from then on to encrypt and decrypt new messages. When older messages arrive that were encrypted using a previous key (exchanged earlier during the same connection), QuantumGate tries other keys from the list in order to decrypt them. Session keys in the list that get too old are destroyed. When the connection closes, all session keys are destroyed.