Javelin™ PQC
Native ML-KEM, ML-DSA, and SLH-DSA for Javelin™ OS deployments, with hybrid ECC + PQC transition support, NIST FIPS 203/204/205 alignment, and a licensable path to production use.
Built for production deployment, hybrid transition, and certification planning.
JAVACARD NATIVE
ML-KEM
ML-DSA
SLH-DSA
NIST FIPS 203 / 204 / 205
Harvest now, decrypt later
Encrypted identity, payment, and authentication data collected today may remain readable after Q-Day.
Signature forgery at scale
Post-CRQC attacks on ECDSA could enable impersonation of trusted credentials and signing authorities.
Deployment lifetime mismatch
Devices approved today may still be active in the Q-Day window, making PQC a manufacturing-time decision.
The Threat Model
ECC still underpins credentials
ECC remains embedded in credential stacks shipping today across identity, payment, travel, and authentication use cases.
Google’s March 2026 research suggested ECC may be broken with far fewer qubits than previously expected. For secure elements and smart cards, PQC is no longer a roadmap topic — it is a procurement requirement.
Algorithm Deep Dive
Three NIST standards
One JavaCard module
From JavaCard runtime to PQC extension layers — structured for deployment, migration, and certification planning.
ML-KEM
NIST FIPS 203
CRYSTALS-KYBER
Key Encapsulation Mechanism
ML-KEM is NIST’s standardized post-quantum key encapsulation mechanism. It replaces classical Diffie-Hellman and ECDH for session key establishment, OTA provisioning, and secure channel negotiation in JavaCard deployments.
TECHNICAL PARAMETERS
Security level
ML-KEM-512 (L1), ML-KEM-768 (L3), ML-KEM-1024 (L5)
Public key size
800–1568 bytes (vs. 64 bytes for P-256)
Ciphertext size
768–1568 bytes
JavaCard API
javacard.security.KeyAgreement (extended)
Use in Javelin
SCP11 PQ variant, OTA key exchange, wallet HD derivation
FIPS status
FIPS 203 — final standard (August 2024)
MIGRATION ARCHITECTURE
Three deployment modes — one migration path
Javelin™ PQC enables a phased migration from classical cryptography to hybrid and PQC-native deployment. Each mode is designed to support real production timelines, certification planning, and gradual rollout.
Mode 1 · Today
Classical
Current deployments
ECDSA / RSA / AES only
Full JavaCard v3.0.5 / v3.2 compliance
Existing applets remain unchanged
No native PQC support
MODE 2 · 2025–2029
Hybrid
Recommended transition
Classical + ML-KEM / ML-DSA in parallel
Dual-signature operation where required
Backward-compatible deployment path
Protected against both classical and quantum attacks
RECOMMENDED NOW
MODE 3 · POST-2029
PQC Native
Target state
ML-KEM, ML-DSA, SLH-DSA only
Classical crypto disabled where required
Full FIPS 203 / 204 / 205 alignment
Lowest long-term attack surface
HYBRID IMPLEMENTATION
Same JavaCard API surface across classical, hybrid, and PQC-native deployment modes
// Javelin PQC™ — hybrid mode, same JavaCard API
Signature sig_ecdsa = Signature.getInstance(ALG_ECDSA_SHA_256, false);
Signature sig_mldsa = Signature.getInstance(ALG_ML_DSA_65, false); // NEW
// Hybrid signing — dual output, one call
HybridSignature.sign(sig_ecdsa, sig_mldsa, data, hybridOutput);
// ML-KEM key exchange — replaces ECDH
KeyAgreement ka = KeyAgreement.getInstance(ALG_ML_KEM_768, false); // NEW
HYBRID IMPLEMENTATION
Same JavaCard API surface across classical, hybrid, and PQC-native deployment modes
// Javelin PQC™ — hybrid mode, same JavaCard API
Signature sig_ecdsa = Signature.getInstance(ALG_ECDSA_SHA_256, false);
Signature sig_mldsa = Signature.getInstance(ALG_ML_DSA_65, false); // NEW
// Hybrid signing — dual output, one call
HybridSignature.sign(sig_ecdsa, sig_mldsa, data, hybridOutput);
// ML-KEM key exchange — replaces ECDH
KeyAgreement ka = KeyAgreement.getInstance(ALG_ML_KEM_768, false); // NEW
Technical FAQ
