Support for Post-Quantum Cryptography in MariaDB TLS Connections

Overview
Quantum computers are emerging machines that use principles of quantum mechanics to perform certain calculations exponentially faster than today’s classical computers. In particular, they can efficiently solve the mathematical problems that underpin classical public-key cryptography (RSA and elliptic-curve algorithms), which are used for key exchange and digital signatures in TLS handshakes. This creates a “harvest now, decrypt later” risk for database traffic: encrypted connections captured today could be decrypted once sufficiently powerful quantum computers become available.

Oracle AI Database 26ai addressed this by adding native support for NIST post-quantum cryptography in TLS 1.3, specifically ML-KEM for key exchange (including hybrid modes) and ML-DSA for digital signatures.

This feature delivers comparable post-quantum TLS capabilities in MariaDB. It includes enhancements to the MariaDB Server as well as updates to the official MariaDB Connectors (Connector/C, Connector/J, ODBC and others) to enable end-to-end quantum-resistant database connections while preserving full compatibility with existing applications and classical TLS setups.

User Story
As a Database Administrator or Application Developer,
I want MariaDB Server and official Connectors to support NIST Post-Quantum Cryptography algorithms for TLS 1.3 key exchange and signatures,
so that our database traffic receives long-term protection against quantum threats with minimal disruption to existing systems.

Terminology
ML-KEM: NIST standardized (FIPS 203) key encapsulation mechanism for quantum-resistant key exchange.
ML-DSA: NIST standardized (FIPS 204) digital signature algorithm for quantum-resistant authentication.
Hybrid mode: Use of both classical and post-quantum algorithms together during the transition period.

Acceptance Criteria

1. When configured on the server, MariaDB shall support ML-KEM and hybrid classical + ML-KEM key exchange during TLS 1.3 handshakes.
2. When a client does not support post-quantum algorithms, the server shall successfully fall back to classical key exchange.
3. The system shall allow the use of server certificates signed with ML-DSA.
4. MariaDB official Connectors shall provide configuration options to enable or prefer post-quantum key exchange groups when connecting to the server.
5. When both the server and connector are configured for post-quantum TLS, they shall successfully negotiate the requested hybrid or PQC algorithms.
6. Handshake algorithm details shall be visible through status variables and log messages for monitoring and troubleshooting.
7. Existing classical-only clients and connectors shall continue to connect without any changes or breakage.

Feature-specific Non-Functional Requirements

1. Security: Implementation shall follow NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and current IETF hybrid recommendations for TLS.
2. Compatibility: Full backward and forward compatibility with classical TLS environments shall be maintained.
3. Performance: Post-quantum handshake overhead shall remain acceptable for typical database workloads, with effective session reuse.
4. Observability: Usage of PQC algorithms shall be trackable in production environments.
5. OSS: Changes shall be contributed under MariaDB’s existing licensing and community contribution model.