Post-Quantum Cryptography support in MySQL

Overview

OpenSSL 3.5 integrates a number of algorithms resistant to attack by future quantum computers, commonly referred as Post-Quantum Cryptography (PQC). These include:

• key exchange algorithms
• TLS handshake signing algorithms
• public-key certificate algorithms

Possibility of storing the vast amounts of TLS encrypted traffic now and decrypting it later once the quantum computers become capable enough is considered a real problem, so the governments and standards bodies mandate transitioning to quantum-safe encryption.

Starting with MySQL 26.7.0, MySQL can use the PQC-capable TLS algorithms provided by OpenSSL 3.5 and later. The initial support focuses on TLSv1.3 connections: PQC-capable key exchange, optional PQC-capable TLS handshake signature advertisement, and observability for negotiated TLS algorithms.

Scope

When MySQL is built with OpenSSL 3.5 or later, TLSv1.3 connections can prefer PQC-capable key exchange groups while keeping classical fallback enabled by default. This lets newer clients negotiate PQC-capable key exchange without breaking the older clients.
The feature applies to these TLS channels:

• Main client-server connections
• Admin connections
• Asynchronous replication
• Group Replication recovery
• Group Replication inter-group channels (MySQL-stack only)
• X Plugin connections

The Group Replication XCom stack is not covered.

PQC-capable TLS handshake signature algorithms are supported as an opt-in feature. Enabling them controls what MySQL advertises or allows during the TLS handshake; it does not generate PQC certificates or require PQC certificates on disk.

Configuration

MySQL exposes three setting families for each supported channel:

Each channel has its own matching variables and command-line options, such as:

• force_pqc, admin_force_pqc, replication_force_pqc, group_replication_force_pqc, mysqlx_force_pqc
• use_pqc_sign, admin_use_pqc_sign, replication_use_pqc_sign, group_replication_use_pqc_sign, mysqlx_use_pqc_sign
• tls_kex, admin_tls_kex, replication_tls_kex, group_replication_tls_kex, mysqlx_tls_kex

Client programs also support --force-pqc, --use-pqc-sign, and --tls-kex.
The corresponding C API options are MYSQL_OPT_FORCE_PQC, MYSQL_OPT_USE_PQC_SIGN, and MYSQL_OPT_TLS_KEX.

Supported Key Exchange Groups

The default preference order favors hybrid PQC groups first, then pure ML-KEM
groups, then classical fallback groups:

Names are case-sensitive. MySQL accepts only the documented names in tls_kex
allow lists.

Example:

[mysqld]
tls_kex=X25519MLKEM768:secp384r1MLKEM1024:X25519

To require PQC-capable key exchange on the main client channel:

[mysqld]
tls_version=TLSv1.3
force_pqc=ON

Enable strict PQC only after testing every required client and server. Older clients, TLSv1.2-only peers, and peers using TLS libraries without the required PQC groups will not be able to connect to a strict PQC channel.

PQC Handshake Signatures

Use following configuration to allow MySQL to advertise PQC-capable TLS handshake signature algorithms:

[mysqld]
use_pqc_sign=ON

When enabled, MySQL can advertise ML-DSA-44, ML-DSA-65, and ML-DSA-87 before classical fallback algorithms. The final negotiated signature algorithm still depends on the peer, TLS library, provider configuration, and available certificates.

Observability

MySQL adds session status variables for inspecting negotiated TLS algorithms:

SHOW SESSION STATUS LIKE 'Tls_key_exchange_algorithm';
SHOW SESSION STATUS LIKE 'Tls_sign_algorithm';

The existing cipher status remains available:

SHOW SESSION STATUS LIKE 'Ssl_cipher';

For the main and admin channels, performance_schema.tls_channel_status includes the current PQC-related channel settings:

• Force_pqc
• Use_pqc_sign
• Tls_kex

For X Plugin, use the effective status variables:

SHOW GLOBAL STATUS LIKE 'Mysqlx_force_pqc';
SHOW GLOBAL STATUS LIKE 'Mysqlx_tls_kex';
SHOW GLOBAL STATUS LIKE 'Mysqlx_use_pqc_sign';

Negotiated algorithm values can be empty when the connection is not using TLS, the TLS session was resumed, or the linked TLS library does not expose the required information.

Deployment Guidance

For most deployments, start with the default behavior: allow MySQL to prefer PQC-capable key exchange while keeping classical fallback available.

Use stricter settings in stages:

1. Confirm that MySQL is linked with OpenSSL 3.5 or later.
2. Confirm that the relevant channels allow TLSv1.3.
3. Leave force_pqc OFF while testing compatibility.
4. Inspect negotiated algorithms with the new status variables.
5. Enable use_pqc_sign only after evaluating provider, certificate, and performance implications.
6. Enable force_pqc only for channels where every required peer can negotiate PQC-capable TLSv1.3 key exchange.

For full option descriptions, channel-specific behavior, and troubleshooting details, see the MySQL documentation.

Conclusion

MySQL’s PQC TLS support gives administrators a practical migration path: prefer quantum-safe key exchange by default, keep compatibility where needed, and enable strict PQC policies when an environment is ready.

Thank you for using MySQL!