Post-quantum cryptography

TLS Integration

Upon the advent of quantum computers capable of breaking classical cryptographic schemes, many of today's widely used public-key cryptographic algorithms (including RSA, DSA, and elliptic curve cryptography) will be rendered insecure. This already poses a serious risk to long-term data confidentiality and authenticity. In so-called harvest-now-decrypt-later attacks, encrypted network traffic is recorded today and stored in anticipation that future quantum computers will be able to decrypt it. Post-quantum cryptography (PQC) mitigates this threat by introducing cryptographic algorithms designed to withstand both classical and quantum attacks.

To help future-proof both front-side and back-end TLS connections, Airlock Gateway proactively integrates support for PQC algorithms in its TLS handshake process. These algorithms are currently integrated in a hybrid mode, meaning they are used in combination with traditional cryptographic algorithms. This hybrid approach ensures forward compatibility with post-quantum standards while maintaining proven classical security.

The use of post-quantum algorithms in TLS in production environments is operationally straightforward:

No security issues are expected from the use of hybrid PQC groups.
Some performance overhead may be observed due to the computational cost of post-quantum algorithms. This is expected and considered acceptable under most conditions.
Clients that do not support PQC will simply negotiate traditional groups (e.g., X25519), maintaining compatibility.

Notice

PQC-based authentication is currently not applicable to public key certificates because relevant standards for post-quantum public key infrastructure are still in development. Therefore, post-quantum public key certificates are neither standardized nor supported by browsers, yet. This makes broad deployment of such certificates currently impossible.

From an IT security perspective, however, this delay is not considered problematic: an attacker would already need access to a highly capable quantum computer today to successfully forge or break authentication mechanisms — a scenario that is currently regarded as highly unlikely. Unlike the confidentiality risks associated with harvest-now-decrypt-later attacks, the risk to authentication remains negligible at the current stage.

PQC in hybrid key exchange groups

PQC algorithms are not used as standalone cipher suites but are part of TLS key exchange groups (also known as ECDHE groups). The only hybrid group currently used in Airlock Gateway is X25519MLKEM768, which combines the classical X25519 key exchange with the post-quantum MLKEM768 algorithm.

Because Airlock Gateway uses OpenSSL for TLS, the hybrid key exchange group is included in the default configuration and is therefore active by default. It is used automatically if supported by the client. This behavior current best practices in cryptographic engineering and ensures that PQC is available without requiring explicit configuration by an administrator.

Logs and Visibility

When a TLS session is established, the selected key exchange group is recorded in the following log message:

WR-SG-TLS-SESS-START

This includes the negotiated TLS group name (e.g., X25519MLKEM768), which provides visibility into whether a PQC-enabled handshake occurred.

Disabling PQC

Currently, OpenSSL does not provide a separate switch to toggle PQC algorithms independently. Therefore, the only option to disable PQC support is to define a custom TLS group list excluding the hybrid X25519MLKEM768 TLS group for post-quantum key exchange. This can be achieved by using the SSLOpenSSLConfCmd Curves directive in the Expert Settings under Security Gate / Apache, either globally or per virtual host. Configuration via mapping is not supported.

Example

SSLOpenSSLConfCmd Curves X25519:prime256v1:secp384r1

Notice

This command explicitly defines the allowed key exchange groups. By omitting X25519MLKEM768, only conventional cryptography is enabled, and PQC is effectively disabled.

Depending on the groups specified, you may switch additional algorithms on or off.
Ensure that the selected group list aligns with your security and compatibility requirements, as specified in the official Apache 2.4 SSLOpenSSLConfCmd directive documentation.

Checking PQC usage in a browser

Google Chrome

Open the website you intent to inspect.
Press F12 or right-click and choose Inspect to open the Developer Tools.
Go to the Security tab.
Under Connection, check in the Key Exchange or Key Agreement field if PQC is used(i.e. X25519MLKEM768
The hybrid PQC group may be listed as follows:
Example
```
X25519MLKEM768
```

Mozilla Firefox

Open the website you intent to inspect.
Press F12 or right-click and choose Inspect to open the Developer Tools.
Go to the Network tab.
Reload the page and click the main document request (usually the first one).
In the Security subtab (on the right), look for Key Exchange Group or Key Exchange.
The hybrid PQC group may be listed as follows:
Example
```
mlkem768x25519
```

Notice

Naming may vary (e.g., X25519MLKEM768Draft00, X25519+MLKEM768, or similar), depending on the browser version.