Share
Embed
Slide 1
Slide 1 text
Theory to Practice:
Real-World Lessons
in Post-Quantum Cryptography Migration
NISHIKAWA, Akihiro (Aki)
Cloud Solution Architect, Microsoft
@logico_jp
@logico-jp.dev
linkedin.com/in/anishi1222/
Slide 2
Slide 2 text
Bonjour!
こんにちは!
Hello!
{
"name": "NISHIKAWA, Akihiro",
"nationality": "Japan",
"work": "Microsoft",
"favourites": [
"JVM",
"GraalVM",
"Azure"
],
"expertise": [
"Application integration",
"Container",
"Serverless"
]
}
Slide 3
Slide 3 text
Agenda Why this matters now?
What can Java already do? What will
Java support?
How to migrate without breaking
production
What to do next
Slide 4
Slide 4 text
TL;DR
Hidden crypto is the first migration problem.
Even one small Spring Boot service hides more crypto than
you would expect.
Java already gives you a path: Bouncy Castle now, hybrid
TLS in JDK 27.
Inventory first. Hybrid key exchange first. Signatures next.
Slide 5
Slide 5 text
Why this matters now?
Slide 6
Slide 6 text
No cryptography stays
safe forever.
Even once-trusted algorithms like DES and
SHA-1 were eventually broken.
RSA and ECDSA have served us well, but they
are not immune to the same fate — especially
in the face of quantum computing.
Slide 7
Slide 7 text
10-year retention period
2036
End of
retention period
2026
Data protected
with RSA/ECC
Slide 8
Slide 8 text
“Harvest Now,
Decrypt Later” (HNDL)
Attackers can capture encrypted
data today and keep it for later
decryption.
Slide 9
Slide 9 text
If “Q-Day” happened in the retention period...
End of
retention period
Data protected
with RSA/ECC
HNDL attack
2026 Q-day 2036
Q-Day.org - Q-Day, Y2Q, PQC, Quantum Readiness, Quantum Security
Slide 10
Slide 10 text
Post-Quantum Cryptography (PQC)
PQC algorithms fall into three main families:
lattice-based (ML-KEM / ML-DSA; historically Kyber / Dilithium)
hash-based (SLH-DSA / SPHINCS+)
code-based (for example HQC)
Each relies on mathematical problems that quantum computers are
not known to solve efficiently.
Slide 11
Slide 11 text
Current NIST PQC Standards — and What Is Next
Source: Post-Quantum Cryptography | CSRC
Approved and in effect
FIPS 203 (ML-KEM): key establishment
FIPS 204 (ML-DSA): digital signatures
FIPS 205 (SLH-DSA): digital signatures
Selected / ongoing standardisation
FN-DSA (FIPS 206 Initial Public Draft, Sep 2025; final expected late
2026 or early 2027)
HQC: additional KEM, draft standard under way
Slide 12
Slide 12 text
Why act now?
Slide 13
Slide 13 text
Research Estimates for Breaking RSA-2048 Are Falling
These are research estimates under specific hardware and error-correction assumptions,
not deployed systems.
How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits – Quantum
[2505.15917] How to factor 2048-bit RSA integers with less than a million noisy qubits
Quantum computers need just 10,000 qubits to break the most secure encryption, scientists warn | Live Science
2025
2019
Mar
2026
20M
noisy qubits,
about 8 hours
~1M
noisy qubits,
under a week
~10k-100k
physical qubits
Architecture-specific estimate (preprint)
Slide 14
Slide 14 text
Awareness is high, but deployment is lagging
65%
69%
are concerned about
HNDL.
expect current
encryption to break
within five years.
5%
have fully deployed
quantum-safe
encryption.
DigiCert, 2025, Survey of 1,042 senior
cybersecurity managers (US, UK, AU)
Capgemini 2025, Survey of
1,000 orgs (≥$1B revenue) in
13 countries
Slide 15
Slide 15 text
Global Government Timelines for PQC Migration
Region Full PQC Transition
United States ~2035 (NSA CNSA 2.0)
European Union ~2035 (EC Recommendation 2024/1101)
United Kingdom ~2035 (NCSC Guidance)
Japan ~2035 (Cabinet Secretariat PQC Council)
Australia ~2030 (ASD/ACSC Roadmap)
Slide 16
Slide 16 text
“It took many organizations
over five years to migrate
from the vulnerable primitive
SHA-1 to its secure successor
SHA-256, even after the
necessary specifications and
implementations were
available.”
– The PQC Migration Handbook
Cryptographic migration takes time
(SHA-1 deprecated 2017; many systems still used it in 2020+)
Slide 17
Slide 17 text
Industry Movement – Recent updates
PQC is now an engineering roadmap, not only a research topic.
2026
JAN
NIST highlighted migration and crypto agility work
CSRC Presentations | CSRC
Frequently Asked Questions about Post-Quantum Cryptography
2026
FEB
JEP 527 completed and shipping in JDK 27 EA
JEP 527 / Inside.java blog / JDK 27 Early-Access Release Notes
2026
MAR
Google linked its 2029 PQC timeline to hardware and
QEC progress
Google’s timeline for PQC migration
Slide 18
Slide 18 text
Why Are Java Applications at Risk?
They live for a long time.
They use crypto everywhere.
Infrastructure changes alone are not enough.
Application integration still matters.
Slide 19
Slide 19 text
What can Java already do?
What will Java support?
Slide 20
Slide 20 text
JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
JEP 510: Key Derivation Function (KDF) API
JEP 496: ML-KEM
JEP 497: ML-DSA
JEP 452: KEM API
(Key Encapsulation Mechanism)
Evolution of PQC support in Java
2023
Sep
2025
Mar
2025
Sep
2026
Sep
Java 21 Java 24 Java 25 Java 27
Slide 21
Slide 21 text
Java PQC Support
What You Can Use Today, and What You Will Be Able To Use Tomorrow
Introduced functionalities Practical path
Java 21 KEM API Use Bouncy Castle where
needed
Java 24 ML-KEM, ML-DSA
Java 25 KDF API
Java 27 Hybrid TLS 1.3 (JEP 527) Prefer hybrid TLS through
standard JSSE APIs
Migration lesson
Start with platform capability
Do not start with hand-written crypto code
Slide 22
Slide 22 text
JEP 527
Post-quantum Hybrid Key Exchange for TLS 1.3
If you use the standard javax.net.ssl APIs, JDK 27 offers
hybrid named groups first in ClientHello.
The handshake goes hybrid when the peer also supports it.
No need to change app code unless you override named groups.
Override with -Djdk.tls.namedGroups=...""
Supported Named Groups
X25519MLKEM768
SecP256r1MLKEM768
SecP384r1MLKEM1024
Slide 23
Slide 23 text
Hybrid TLS 1.3
X25519MLKEM768 – only what you need to know
3. Both sides derive two shared secrets:
X25519 + ML-KEM
🖥 Client 🌐 Server
2. ServerHello selects the group
and returns a hybrid key share
4. HKDF combines them into one handshake secret
1. ClientHello offers a hybrid group
(e.g., X25519MLKEM768)
NOTE: Certificates can stay RSA or ECDSA for now.
JEP 527 changes key exchange first.
Slide 24
Slide 24 text
How to migrate without breaking production
This is not only a standards problem.
It is an estate-discovery problem.
First find the hidden crypto.
Then decide what moves first.
Slide 25
Slide 25 text
1. Inventory
Identify TLS endpoints, cipher suites, mTLS, cert stores.
Catalogue code/JAR signing, JWT/OIDC/SAML algorithms.
Locate custom cipher usages and data-at-rest encryption.
Use static analysis/scanners for API/algorithm detection.
Dependency libraries
Configuration
Certificate OIDs (Object Identifiers)
Map sensitive data and required secrecy lifetime.
Slide 26
Slide 26 text
A Practical Four-Layer Crypto Inventory for Java
Each layer covers a blind spot from the others. One grep is never enough.
1. Dependencies
What crypto comes in through libraries or drivers?
2. Source & frameworks
3. Config & KeyStore
4. Runtime capability & Evidence
Where does the application ask for crypto?
What enables crypto with almost no Java code?
What the JVM could use, and what it actually used under real traffic?
Slide 27
Slide 27 text
Layer 4 Needs Two Views
Capability
JCE providers
supported cipher suites
supported named groups
Evidence
JFR TLS handshakes
X.509 validation
security events
Outside the JVM
Edge TLS / Managed crypto / External identity
For TLS 1.3: cipher suite != key exchange group
Check named groups as well
Slide 28
Slide 28 text
Where Does Crypto Hide?
A typical Spring Boot microservice — how many crypto usage points can you spot?
src/main
├── java/com/example/pqcdemo
│ ├── config
│ │ └── SecurityConfig.java
│ ├── controller
│ │ └── ApiController.java
│ ├── PqcDemoApplication.java
│ └── service
│ ├── EncryptionService.java
│ ├── HmacService.java
│ ├── JwtService.java
│ └── LicenseService.java
└── resources
├── application.properties
└── keystore.p12
DEMO Code:
https://github.com/anishi1222
/find-crypto-usages
Slide 29
Slide 29 text
What The Audit Finds - Dependencies
Review first
JWT signing libraries
database drivers using TLS
general-purpose crypto providers
■ Quantum-vulnerable
■ Needs review
■ Low-risk
■Nimbus JOSE+JWT JWS — RSA signing inside framework
■Bouncy Castle General-purpose crypto provider
■Google Tink Algorithm hidden in key template
■Spring Security BCrypt, crypto utilities
■PostgreSQL JDBC TLS via driver configuration - easy to miss in code review
■Commons Codec Hashing/encoding utilities
■JDK built-in JCA/JCE Always available
Slide 30
Slide 30 text
What The Audit Finds - Source and Configuration
JCE / JCA API Calls ■ KeyStore.getInstance (2 files)
Configuration ■ server.ssl.enabled=true
■ datasource sslmode=verify-full
Framework /
Library Patterns
■ NimbusJwtEncoder (RS256 signing)
■ NimbusJwtDecoder (RS256 verification)
■ JcaContentSignerBuilder (SHA256withRSA)
■ Tink AEAD (AES-256-GCM)
■ Tink KeysetHandle
■ BC CMS / SignerInfoGenerator
■ BC HMac + SHA256Digest
Slide 31
Slide 31 text
What The Audit Finds – KeyStore
Indeed quantum-vulnerable, but...
■RSA-2048 server key
■RSA-signed certificate chain
Used for HTTPS authentication in this service
Same keystore is also referenced by JWT and licence flows in this demo
Needs review for certificate and signature migration
Does not prove the negotiated TLS named group
Slide 32
Slide 32 text
What The Audit Finds – JFR Runtime Audit
Static analysis might miss
runtime-only crypto behaviour
TLS handshakes
X.509 validation
security-property changes
deserialization-related
security events
Enable events below and
capture with jcmd or a custom
.jfc file
jdk.TLSHandshake
jdk.X509Validation
jdk.X509Certificate
jdk.SecurityPropertyModification
jdk.Deserialization
Slide 33
Slide 33 text
How to Prove Hybrid TLS in Practice
Built-in runtime evidence
JFR / JDK Mission Control
protocol version
cipher suite
certificate-validation events
Exact named-group proof
JSSE handshake debug
packet capture
custom audit event
Practical rule
JFR shows what happened
one extra source proves the exact named group
Slide 34
Slide 34 text
Crypto is everywhere, and much of it is invisible.
Quantum
vulnerable
Need
review
Low risk Total
5 14 3 22
Slide 35
Slide 35 text
2. Prioritisation
❶ data
in transit
❷ long-lived
encrypted data
❸ code
signing
Slide 36
Slide 36 text
Why HNDL Targets Key Exchange, Not Authentication
ClientHello
key_share: X25519 / X25519MLKEM768
🔑 Shared Secret derived here
🖥 Client 🌐 Server
Application Data
Application Data
ServerHello
key_share: X25519 / X25519MLKEM768
Certificate + CertificateVerify
RSA / ECDSA signature
🔑 Server identity verified here
This is what HNDL targets:
Break the key exchange =
decrypt ALL past sessions
HNDL does NOT apply.
Break the signature =
forge future sessions only
■ Key Exchange ■ Authentication
HNDL risk Past sessions decryptable No retroactive impact
Time pressure Now (data already captured) Later (future threat only)
Slide 37
Slide 37 text
HNDL threatens the exchange, not authentication.
KEM protects
past confidentiality.
Signatures protect
future impersonation risk.
Slide 38
Slide 38 text
3. Hybrid
Use hybrid mode to reduce transition risk while the ecosystem is
mixed.
Hybrid = classical + PQC during transition
Pure PQ = likely future end state in controlled ecosystems
Use hybrid when interoperability is uncertain
Use pure PQ only when you control and can test both ends
Slide 39
Slide 39 text
PKI Certificate Migration
Private PKI pilot only — not a near-term public-web recommendation
Today
Move hybrid key exchange first for HNDL protection
Pilot certificate changes only where you control both ends
Test trust stores, chain validation, and certificate-size impact
Keep RSA/ECDSA on the public web until browser, CA, and standards support is
ready
Decision rule
Controlled ecosystem: experiment
Open ecosystem: wait
Slide 40
Slide 40 text
key_share size is much bigger, but...
Item
Classical
(X25519)
Hybrid
(X25519MLKEM768)
ClientHello key_share 32 bytes 1,216 bytes (32 + 1,184)
ServerHello key_share 32 bytes 1,120 bytes (32 + 1,088)
Shared-Secret Input (HKDF) 32 bytes 64 bytes (32 + 32)
(concatenated, fed into HKDF)
Classical: X25519 (RFC 7748)
Hybrid: X25519MLKEM768 (draft-ietf-tls-ecdhe-mlkem)
Slide 41
Slide 41 text
Why Is Hybrid Hard on TLS 1.2?
Not impossible, but significantly harder than TLS 1.3.
Three practical blockers
Cipher-suite rigidity
Message size and middleboxes
IETF feature freeze
Practical advice
Upgrade to TLS 1.3 first, then add hybrid TLS.
Slide 42
Slide 42 text
4. Crypto-Agility
Change crypto policy and algorithms with minimal code change.
Use inventory, configuration, and rollback to make migration
repeatable.
Slide 43
Slide 43 text
Why?
Resilience
If one approved option changes, you can move to another with less disruption.
Testing
Roll out gradually, measure behaviour, and revert quickly if needed.
Engineering effort
Refactor hard-coded crypto before migration pressure arrives.
Slide 44
Slide 44 text
Bad code...
//" hardcoded! Signature
sig = Signature.getInstance("SHA256withRSA");
//" hardcoded!
KeyPairGenerator kpg
= KeyPairGenerator.getInstance("RSA", "SunRsaSign");
Slide 45
Slide 45 text
Design Principles
No hard-code algorithm names or parameters
Externalise choices in configuration
Abstract crypto behind interfaces
(strategy pattern)
Leverage JCA provider abstraction
Keep provider choice out of business code
Prepare fallback toggles and feature flags
Config file
SignatureService
RSASigner
Specify
algorithm
(ML-DSA, RSA, etc.)
sign()
verify()
MlDsaSigner
Interface
Slide 46
Slide 46 text
Configuration
e.g., application.yml
Keep three things in configuration:
1. Separate modes by track
2. Use JCA Standard Names /
complete transformations
3. TLS named-group order
tls:
key-exchange-mode: hybrid
named-groups:
- X25519MLKEM768
- x25519
certificates:
mode: classical
application-signatures:
mode: classical
legacy-verify-allowed: true
Slide 47
Slide 47 text
TLS configuration
JDK 27 default
X25519MLKEM768 is enabled by default.
Override when needed
JVM-wide: jdk.tls.namedGroups
Per-connection: SSLParameters::"setNamedGroups(..."")
Earlier JDKs
Use provider-specific paths only if you need hybrid TLS.
Slide 48
Slide 48 text
5. Phased Approach — Two Dimensions
at the edge, or
at the trust core?
key exchange, or
authentication?
Where to start
What to move first
Slide 49
Slide 49 text
Topology Comparison
Outside-in (edge-first)
First step: upgrade the edge TLS path
Best for public web and mobile
systems
Faster change, narrower blast radius
Inside-out (trust-core-first)
First step: map internal trust
dependencies and controlled service-
to-service domains
Best for tightly controlled internal
ecosystems
Slower change, broader coordination
Note: topology order and primitive order are separate axes
Slide 50
Slide 50 text
Hybrid TLS Hybrid TLS
Hybrid TLS
Outside-in 3 Phases
Roll out hybrid TLS in phases.
Keep backward compatibility.
Introduce hybrid certificates only where the client ecosystem is
controlled.
Backends
Java app
CDN/Proxy
Client
Classic TLS Classic TLS
Classic TLS
Slide 51
Slide 51 text
Primitive Axis
KEM First, Authentication Later.
Ready today
• Hybrid key exchange in TLS
• Java 27 / JEP 527
• Browser and CDN deployment
paths
Later
• PQC certificates for TLS
authentication
• RFC maturity
• JSSE integration
• Browser and CA ecosystem
readiness
Keep RSA/ECDSA certificates until the ecosystem is ready.
Slide 52
Slide 52 text
6. Performance & Operational Impact on TLS
Bulk cipher unchanged — AES/HKDF run at the same speed.
Still measure:
CPU / memory per handshake
p50 / p95 handshake latency under real traffic
connection-reuse rate (handshake cost amortises here)
Handshake size and middlebox risk are on the earlier
"key_share" slide.
Slide 53
Slide 53 text
7. Testing Strategy
1. Interoperability - Cross-implementation
(Java ↔ OpenSSL-based PQC TLS stack)
- Hybrid TLS handshakes
2. Performance - Handshake latency
- CPU/memory
- Throughput
3. Fallback and rollback - Classical fallback paths
- Legacy clients
- Graceful failure modes
4. Policy enforcement - Allowed / denied algorithms
- Visible constraint failure
Slide 54
Slide 54 text
2025 2026 2027 2028 2029 2030
Discover
Protect
Expand trust
Retire legacy
8. Migration Timeline — Anonymized Customer Case
JDK 27 released in September 2026
Why it took longer than expected
- 200+ services / 3,000+ touchpoints, mostly on Java 17
- 60%+ of crypto sat outside the security module
- Same 4-layer model as the demo — just at estate scale
Slide 55
Slide 55 text
Top Migration Blockers — and the Practical Response
Network - test larger handshakes on the real path
- use canary rollout and fallback
Certificates
and keys
- start with private PKI
- plan for larger keys, signatures, and chain size
Libraries and
vendors
- pin versions
- test upgrades separately
- ask vendors for PQC timelines early
Operations - capture runtime evidence
- monitor fallback to classical-only paths
- prepare rollback before rollout
Slide 56
Slide 56 text
What to do next
Slide 57
Slide 57 text
Key Takeaways: Three things to remember
Inventory
You cannot migrate what you cannot find.
Hybrid key exchange
The practical bridge during transition.
Not the permanent end state.
Start now
Migration spans years, not months.
Slide 58
Slide 58 text
Call to Action
… and ask key vendors for their PQC roadmap.
Developers
Architects
Security leads
Managers
Check runtime providers / TLS evidence
Externalise algorithm and provider choice
Build a Java 27 hybrid-TLS PoC now
Plan production adoption on the first suitable LTS
carrying JEP 527
Brief leadership on HNDL risk
Fund the roadmap and ask key vendors for their PQC
timelines
Slide 59
Slide 59 text
Start this week!
Run keytool -list -v on one service keystore
Do one 4-layer crypto inventory on that same service
Test one hybrid TLS path with JDK 27 EA or a
provider-specific hybrid-TLS stack
That is how PQC migration starts in the real world.
Slide 60
Slide 60 text
Merci beaucoup!
ありがとう!
Thank you!