Expert technical analysis on quantum computing, post-quantum cryptography, and quantum-safe infrastructure for Ireland and the EU.
Quantum-Safe Infrastructure | Blockchain | Clonmel, Co. Tipperary, Ireland
Meta Description: NIST FIPS 203 (ML-KEM) explained by Michael English, Irish tech entrepreneur and CTO of IMPT.io. What the new quantum-safe standard means for Irish businesses and EU compliance.
Target Keywords: NIST FIPS 203 Ireland, ML-KEM post-quantum cryptography, quantum-safe encryption Ireland, post-quantum standards EU, Michael English quantum computing
In August 2024, the United States National Institute of Standards and Technology (NIST) published Federal Information Processing Standard 203 — the world's first government-endorsed post-quantum key encapsulation standard. For Irish technology companies, financial institutions, and critical infrastructure operators, FIPS 203 represents the starting gun for quantum-safe migration.
The standard formalises ML-KEM (Module Lattice-based Key Encapsulation Mechanism), formerly known as CRYSTALS-Kyber — an algorithm that can protect data against both classical and quantum computer attacks. In this article, I'll break down exactly what ML-KEM does, how it differs from the classical encryption Irish businesses use today, and what practical steps you should take.
Most encrypted internet traffic today — your HTTPS web sessions, VPN connections, API calls, and SSH tunnels — uses key exchange based on either RSA (Rivest–Shamir–Adleman) or ECDH (Elliptic Curve Diffie-Hellman). These algorithms work because:
In 1994, mathematician Peter Shor proved that a sufficiently large quantum computer could solve both of these problems efficiently using quantum superposition and interference. A quantum computer with approximately 4,000 logical qubits (or ~4 million physical qubits with current error rates) could break 2048-bit RSA in hours.
ML-KEM replaces RSA and ECDH with a fundamentally different mathematical problem: the Module Learning With Errors (MLWE) problem. Unlike IFP and DLP, MLWE is believed to be hard for both classical and quantum computers — a property proven under worst-case assumptions about random lattice problems.
ML-KEM is a Key Encapsulation Mechanism (KEM) — a type of asymmetric encryption optimised for the specific task of securely establishing a shared symmetric key between two parties.
Given:
Compute b = As + e mod q
The MLWE problem asks: given (A, b), recover s. This is believed to be computationally hard even for quantum computers, with the best known attacks requiring exponential time.
KeyGen():
A ← sample uniform matrix (via AES-CTR DRBG from seed ρ)
(s, e) ← sample small secret and error vectors
pk = (A, b = As + e mod q) # public key
sk = s # secret key
Encaps(pk):
m ← sample random 32-byte message
(r, e₁, e₂) ← small random vectors derived from m, pk
u = Aᵀr + e₁ mod q
v = bᵀr + e₂ + encode(m) mod q
K = KDF(m) # shared secret
c = (u, v) # ciphertext
return (c, K)
Decaps(sk, c):
m' = decode(v - sᵀu mod q)
K = KDF(m')
return K
The correctness condition relies on the error terms being small: the decoded message m' equals m with overwhelming probability.
FIPS 203 specifies three parameter sets, corresponding to three security levels:
| Parameter | q | k | η₁ | η₂ | d_u | d_v | PK size | CT size | Security |
|---|---|---|---|---|---|---|---|---|---|
| ML-KEM-512 | 3329 | 2 | 3 | 2 | 10 | 4 | 800 B | 768 B | Level 1 |
| ML-KEM-768 | 3329 | 3 | 2 | 2 | 10 | 4 | 1184 B | 1088 B | Level 3 |
| ML-KEM-1024 | 3329 | 4 | 2 | 2 | 11 | 5 | 1568 B | 1568 B | Level 5 |
Security Level 1 ≈ AES-128 — appropriate for most commercial applications
Security Level 3 ≈ AES-192 — recommended for sensitive commercial data, financial services
Security Level 5 ≈ AES-256 — for high-security government, defence, or long-lived sensitive data
ENISA recommendation for EU organisations: ML-KEM-768 (Level 3) as the default, providing substantial security margin with manageable overhead.
A common concern is whether PQC algorithms are too slow for production use. The answer, for ML-KEM, is clearly no:
Benchmarks on Intel Core i7-10510U (single core):
For comparison, ECDH P-256 (the most common classical alternative) takes ~117 microseconds for a full key exchange on the same hardware. ML-KEM is actually faster than the algorithm it replaces for key exchange.
The cost is in key and ciphertext sizes: ML-KEM-768's 1184-byte public key is larger than a 64-byte ECDH public key, but this is easily accommodated within TLS handshakes and modern network conditions.
The IETF has standardised hybrid key exchange for TLS 1.3 in draft RFC 9370, combining classical ECDH with ML-KEM:
TLS_HYBRID_ECDH_X25519_MLKEM768
This combination computes the shared secret as:
K = KDF(K_ECDH || K_MLKEM768)
Where:
Both must be correct for the session to establish. This provides protection against both:
Current deployment status (2025):
network.tls.enable0rttdataThe Digital Operational Resilience Act requires Irish financial entities to demonstrate cryptographic agility by January 2025. Deploying hybrid TLS with ML-KEM on customer-facing APIs and internal service mesh satisfies the "state of the art cryptography" requirement while maintaining compatibility.
Action: Audit your API gateways, load balancers (AWS ALB, Nginx, HAProxy), and internal service communication for TLS version and cipher suite support. Upgrade to TLS 1.3 with hybrid cipher suites as a first step.
Irish healthcare data under GDPR must remain protected for decades. Patient records encrypted today with AES-256 for data-at-rest are quantum-safe; however, the key exchange used to distribute those AES keys (typically RSA or ECDH) is not. Migrating to ML-KEM for key exchange protects the entire encryption stack.
Action: Review your key management service (KMS) and HSM vendor's PQC roadmap. Major vendors (Thales, Utimaco, AWS CloudHSM) are releasing PQC-capable firmware.
For Irish tech companies serving EU enterprise customers, demonstrating PQC readiness is becoming a procurement differentiator. EU public sector tenders increasingly include cryptographic requirements aligned with ENISA guidance.
Action: Add PQC support to your product roadmap, publish a quantum readiness statement, and engage with ENISA's PQC Working Group publications.
The Open Quantum Safe (OQS) project provides production-quality implementations:
# Install liboqs (C library)
git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake .. -DOQS_USE_OPENSSL=ON
make -j4 && sudo make install
# oqs-provider for OpenSSL 3.x integration
git clone https://github.com/open-quantum-safe/oqs-provider.git
# Follow build instructions for OpenSSL provider integration
For Python developers:
pip install oqs-python
import oqs
with oqs.KeyEncapsulation("ML-KEM-768") as kem:
public_key = kem.generate_keypair()
ciphertext, shared_secret_enc = oqs.KeyEncapsulation("ML-KEM-768").encap_secret(public_key)
shared_secret_dec = kem.decap_secret(ciphertext)
assert shared_secret_enc == shared_secret_dec # Key exchange successful
"We should wait for the standard to mature before implementing it." — The standard has been through 8 years of global cryptanalysis. Waiting only increases harvest-now-decrypt-later risk.
"Our data isn't sensitive enough to worry about quantum." — If your business handles customer PII, financial data, or health information, GDPR breach notification requirements apply regardless of how the breach occurs.
"Quantum computers that can break encryption don't exist yet." — True, but the harvest-now-decrypt-later attack does not require a quantum computer to exist today. Data stolen today can be decrypted in 10 years.
"Switching to FIPS 203 will break our systems." — Hybrid deployments maintain full backwards compatibility while adding quantum protection. The transition can be phased with zero downtime.
NIST FIPS 203 (ML-KEM) is the most significant advance in commercial cryptography since AES standardisation in 2001. For Irish and EU organisations, it provides a clear, battle-tested path to quantum-safe encryption that can be deployed today in hybrid mode, providing immediate security improvements with full backwards compatibility.
The algorithm is fast, well-understood, and supported by an expanding ecosystem of open-source and commercial implementations. There is no longer any technical barrier to beginning migration — only organisational inertia.
Michael English is Co-Founder & CTO of IMPT.io and a recognised voice on post-quantum cryptography in Ireland and the EU. He advises Irish tech companies on quantum-safe infrastructure and compliance. Based in Clonmel, Co. Tipperary.
Keywords: NIST FIPS 203 Ireland, ML-KEM explained, post-quantum cryptography Ireland, quantum-safe TLS Ireland, CRYSTALS-Kyber standard, quantum computing EU compliance, Michael English cryptography