Post-quantum cryptography in Spring Boot: four patterns Java devs can use today

An article published on InfoQ by Pankaj Sharma and reviewed by Michael Redlich details four concrete patterns for applying post-quantum cryptography (PQC) in Spring Boot applications. The central point is that much of this is already possible today, without waiting for post-quantum TLS to reach the cloud provider, and that teams in regulated sectors (banks, fintechs, insurers) have reasons to start now.

What's already available in the JDK

According to the article, if your application already runs on JDK 24, you can use the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) through the Java Cryptography Extension (JCE) API itself, without any external library. These algorithms were added to the SunJCE provider via JEP 496 and JEP 497, corresponding to the FIPS 203 and FIPS 204 standards that NIST finalized in August 2024.

The native code is straightforward:

// JDK 24+, no Bouncy Castle
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM-768");
KeyPair kyberPair = kpg.generateKeyPair();

Signature signer = Signature.getInstance("ML-DSA-65");
signer.initSign(dilithiumPrivateKey);
signer.update(message);
byte[] sig = signer.sign();

For those still on JDK 11 or 17, the article points to Bouncy Castle (bcprov-jdk18on) as a compatible path, with more parameter flexibility. The recommendation is: if the bank already plans to move to JDK 24, it's worth taking the native route, which has zero dependencies and is where NIST-aligned Java tooling is converging.

The threat: harvest now, decrypt later

The article is emphatic about separating real risk from hype. RSA and ECDSA rely on the difficulty of factoring large numbers and solving discrete logarithms on classical computers. Shor's algorithm running on a quantum computer solves both in polynomial time. IBM, Google, and national labs already have quantum processors, but none at the scale needed to break RSA-2048. Most experts place that crossover between 2030 and 2035.

What can't wait is the Harvest Now, Decrypt Later (HNDL) attack: adversaries intercept and store encrypted TLS traffic today, along with the RSA key exchange, to decrypt it later. A CPF (Brazil's individual taxpayer ID), KYC data, or transaction record captured now will still be useful in 2035.

The second irreversible problem is long-lived signed documents. A loan contract signed today with RSA will have a forgeable signature around 2035, and banks archive these documents for seven to thirty years, depending on the jurisdiction. There's no way to retroactively re-sign archived contracts.

The four patterns

The text uses as its scenario a banking microservices platform in Spring Boot, with a Transaction Service sending payment instructions to a Core Banking Service, PII and KYC data in PostgreSQL, contracts archived in S3, and OAuth2 tokens in regulatory pipelines. The patterns use a library called PqcStarterLib, which exposes three auto-configurable beans (PqcEncryptionService, PqcSignatureService, and PqcKeyPairGenerator).

1. Payload encryption between services. Encrypt the HTTP body with Kyber + AES-256-GCM before sending, independent of TLS. Since TLS is often terminated at gateways and service meshes (leaving the internal hop in plaintext), this double layer protects data even if TLS is stripped. The article warns: Kyber-768 public keys are about 1,184 bytes (fine in the body, not in headers), and Dilithium-3 signatures reach 3,300 bytes, which weighs heavily on JWT claims or ISO 20022 envelopes.

2. Field-level encryption for PII and KYC. Encrypt each sensitive field (CPF, tax ID, date of birth) before persisting it with Jakarta Persistence, storing a base64 blob in the column and marking the plaintext value as @Transient.

3. Signing of long-lived documents. Sign contracts and audit trails with Dilithium at creation time. A signature made today remains cryptographically valid in 2045, and the same pattern applies to signing CI/CD artifacts, with the deploy gate verifying the signature before any kubectl apply.

4. Signing of OAuth2 tokens for service accounts. Client session tokens that expire in fifteen minutes are low risk; service account tokens for Core Banking, fraud detection, and SWIFT connectors, on the other hand, live for months or years, making them a priority target for HNDL.

The sticking point: key management

The article is honest about what doesn't go straight to production. Encrypting a field with a Kyber key is the easy part. The hard part is guaranteeing that the private key never lives in the JVM heap. In the field-level example, masterKeyPair.getPrivate() is a Kyber key in memory, and that creates three problems that fail any audit: a restart without a persistent key store makes all encrypted records permanently unreadable; a heap dump exposes the master key for every CPF in the bank; and there's no key rotation, which GLBA, PCI-DSS, and SOC 2 require.

The fix, according to the text, is to route all key operations through AWS KMS or HashiCorp Vault, so that the application never holds the raw private key and every decrypt is a logged, auditable call. This is an engineering effort separate from the cryptography itself, and it needs to be ready before any encrypted field gets anywhere near production. Without it, what exists is a proof of concept, not a deployable system.

What changes for those building software in Brazil

The article's practical recommendation translates well to the local context. The LGPD (Brazil's data protection law) treats data like CPF and KYC information as personal and sensitive, with the same exposure consequences the text cites for GDPR, CCPA, and GLBA. Teams at banks, fintechs, payment providers, and the Pix (Brazil's instant payment system) ecosystem deal precisely with long-lived data and settlement messages, exactly the profile the text classifies as an HNDL target.

The central advice is to prioritize migration based on which data lives longest, not on the authorization layer that feels more familiar: contracts and KYC records signed with RSA today will have forgeable signatures around 2035, with no chance of a later fix. For the Brazilian Java developer already planning a JDK version upgrade, the message is that the upgrade to JDK 24 itself unlocks the PQC journey, since ML-KEM and ML-DSA become part of the standard library.

What remains open is the surrounding ecosystem: post-quantum TLS is still being rolled out across cloud providers, KMS/Vault integration with Kyber key operations is additional engineering work, and the PqcStarterLib cited is an example library from the article, not an official standard. For production, the JDK's native path combined with a key management service is the most solid foundation the text points to.