algorithms that run on today's computers, built to resist future quantum attacks • This is engineering work, not a maths lecture • Start with TLS. Then check what TLS does not cover • Byte-level detail lives in the appendix
not one switch. • JEP 527: a strong pilot path for hybrid TLS 1.3 in SunJSSE • It helps HTTPS key exchange — it does not migrate the app • Pick one real Java service. Find every crypto touchpoint • Name an owner and evidence for each one • Choose one reversible hybrid TLS pilot
every algorithm must change. • At risk: RSA, Diffie-Hellman, ECDH, ECDSA • They agree keys, sign messages, prove identity • AES, SHA-2, SHA-3, HMAC — policy review, not first target • Find the public-key decision points first
NCSC point across this decade and the 2030s • Scoped guidance — not one universal deadline • Your date depends on system, jurisdiction, regulator • Work backwards from the date you must be ready • Month one is discovery, ownership, vendors, partners
touchpoints across apps, JDKs, libraries, keys, certs • Most sat outside the security module. Ownership was fragmented • Manual review did not scale • What worked: a four-layer inventory • What failed: runtime capability treated as route evidence — the edge terminated TLS
today, break the public-key part later • For recorded TLS, the decision that matters is key exchange • Hybrid TLS 1.3: clear scope, reversible change • But the first pilot is not always the biggest risk • Rank stored data by how long it must stay secret
Forgeable signatures mean impersonation — certs, JWTs, receipts • That is not the same as decrypting old captured traffic • Confuse the clocks and you delay the work that helps HNDL • The answer is not either-or. It is sequencing
support PQC?" • Building blocks: ML-KEM, ML-DSA, KDF • JEP 527 connects them to one surface: hybrid TLS 1.3 in SunJSSE • JEP 527 helps Track T — not objects, certs, KeyStores, HSM, partners • Oracle plans hybrid TLS across LTS lines, JDK 8 to 25 • A vendor roadmap is not deployed evidence
gives you ML-KEM or ML-DSA — nothing more • Each use case still needs a standard, a library, key material • Plus an owner and evidence • JWT, CMS, XML Signature, JAR signing, KeyStores mature separately • Track readiness per use case, not as one Java-wide status
hybrid group such as X25519MLKEM768 • Session secret combines classical X25519 and ML-KEM • An attacker must break both — that is the HNDL reduction • RFC 10024 puts the three ECDHE-MLKEM groups on the Standards Track • Delivered in JDK 27; GA planned 15 September 2026 • Record protection still uses normal AEAD ciphers
• Classical fallback may be permitted — visible, owned, time-bounded • Hidden fallback means unmeasurable HNDL exposure • TLS 1.2 is a separate problem: move candidates to 1.3 first
before lunch. • Build — crypto libraries and TLS implementations • Source — crypto calls and algorithm strings • Config — KeyStores, TrustStores, TLS settings, endpoints • Runtime — evidence from the real route or object • Record owner, control point, and evidence for each hit
control point, behaviour, evidence • Track T · edge platform · public gateway · TLS 1.3 X25519 · gateway log • Blank owner, control point, or evidence = not ready for a decision • One service by hand teaches the method • You scale it with an automated crypto inventory in CI
Security, DB driver, Bouncy Castle, JDK providers • Source: explicit crypto calls and algorithm strings • Config: TLS settings, KeyStores, certificates • Runtime: JFR shows TLS and certificate activity • Limit — JDK 27 JFR does not record the negotiated group • Hidden crypto becomes a backlog. Not yet proof
often hidden behind framework APIs. 🔴 Spring Security: NimbusJwtEncoder signs JWTs with RSA. 🟡 Bouncy Castle: JcaContentSignerBuilder takes the signing algorithm as an argument. 🟡 Spring Boot: server.ssl.* enables TLS with almost no Java code. Keyword grep alone is not enough. • Read framework configuration and builder calls.
the full TLS story 🔴 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.
prove the negotiated group. • Client allows only the hybrid group and forces TLS 1.3 • Server allows only the same group • A successful handshake proves the group was selected • JSSE handshake debug captures the offer and the selection • Paired ClientHello and ServerHello = Level 3 evidence
can do it 2. Configuration — the service asks for it 3. Technical proof — the real route or object shows it 4. Business proof — the real client or partner accepts it 5. Operational proof — monitoring, rollback, owner, expiry Level 1 or 2 is preparation, not migration complete
different rules during migration • Encrypt-new, decrypt-old. Sign-new, verify-old • Every exception needs an owner, a reason, and an expiry • Bad: algorithm names hard-coded in business logic • Good: business code asks for a use case; policy supplies the rest
Signature.getInstance("SHA256withRSA") directly • Good • business code asks for a use case; policy supplies the rest • Policy layer supplies • algorithm, provider, key alias, validity, rollback • JWT policy: RS256 today, move only when everyone is ready • Default design for new Java services from day one
certificates: mode: classical application-signatures: mode: classical Keep four things in configuration: 1. Separate modes by migration track 2. Use standard names and complete transformations 3. Keep TLS named-group order outside code 4. Keep message-protection provider and message-protection: policy outside code cms-smime-mode: classical-baseline provider: BC content-cipher: AES/GCM/NoPadding key-wrap: RSAES-OAEP oaep-digest: SHA-256 oaep-mgf: MGF1 oaep-mgf-digest: SHA-256 oaep-label: empty pqc-pilot-target: ML-KEM-based CMS recipient flow when provider and peers are ready legacy-verify-allowed: true
from a stable TLS 1.3 baseline • Pilot hybrid key exchange • Keep the hybrid group and classical fallback visible • Level 3 only when proof comes from the route you care about • Clear risk model, clear boundary
a session negotiated it • Resumed sessions do not show the same signal — test both • Larger ClientHello: middleboxes may drop it, showing as timeouts • JDK 27 puts the hybrid group first by default • Treat the JDK upgrade itself as a routelevel rollout item
If traffic ends at a CDN or LB, backend JVM settings change nothing • Service-to-service: SunJSSE may be the control point • Mesh, database, broker, partner gateway own part of the decision • Name five things: boundary, control point, evidence, fallback metric, rollback • Collect evidence at the same boundary as the control point
the pipe — the objects the app creates, stores, sends • Signed: sign-new, verify-old-and-new during coexistence • Encrypted: encrypt-new, decrypt-old-and-new • Record creator, consumer, key, and how long old objects live • Done only when the real format works end to end — and rejects bad input
the session key comes from the ephemeral exchange • An RSA or ECDSA certificate can still use the hybrid group • Certificates solve a different problem: future impersonation • Plan CA hierarchy, TrustStore, renewal, revocation, pinning, validation
often the blocker. • You cannot convert an RSA key into ML-DSA or ML-KEM • Create new key material alongside the old • Check the real path: key types, provider, rotation, backup, recovery, audit • Certificates, signatures, and partners all depend on keys • An untracked fallback is a downgrade, not a safe mode
• Transport may follow Track T — the message layer is separate • Name partner, gateway, security profile, test artefact, fallback, cutover • AS2 and AS4 use different message-security stacks • An HTTPS upgrade alone proves nothing about the message path
the handshake. • Choose a boundary. Name the owner. Find the control point • Run a small pilot. Collect proof. Keep fallback visible • Define rollback. Monitor exceptions • T is the reference case; S coexists objects; C plans PKI • K coexists keys; P tests bilaterally
• Track T often moves first — it reduces HNDL and you control it • Track K discovery starts in parallel: everything depends on keys • Track P cuts over late, but the conversation starts early • The goal is not solving every track at once
Security: the real route proves negotiation and visible fallback • Compatibility: real clients complete the workflow • Operations: baseline, thresholds, rollback action, owner • A metric without a threshold is observation, not a gate
• Standards, libraries, providers, and partners keep changing • Start-up checks, runtime telemetry, policy exceptions, CI checks • Exceptions need an owner, a reason, and an expiry • Without observability, old algorithms return through a dependency bump • Watch negotiation, fallback, cert and key lifecycle, exceptions
boundary and evidence. • "Java supports PQC" — which track? • "The provider supports it" — did the real route or object use it? • "The partner is ready" — which version, profile, test, rollback owner? • These questions protect the plan from overclaiming
• Quantum risk starts with public-key crypto • JEP 527 gives Track T a path — not the whole application • Readiness is evidence, not capability • Plan all tracks in parallel; sequence production • New service? Put the seams in before release Monday: one service, five fields, one reversible Track T pilot
logico_jp
polidog
rfdnxbro
gpuunite_official
ytaka23
optim
kokiko
puhitaku
_awache
sansan33
naoinaoi
takapy
malarkey
swwweet
tapps
tammyeverts
eitanlees
speakerdeck
jonrohan
kimpetersen
mojombo
konakalab
inesmontani
honnibal
![Configuration – e.g. application.yml tls: key-exchange-mode: hybrid named-groups: [X25519MLKEM768, x25519]](https://files.speakerdeck.com/presentations/52274fff998f4afaaef25759b888d863/slide_36.jpg){kind=link}
