Cryptographic APIs & Developer Languages
Compare JCA/JCE, OpenSSL, PKCS#11, CNG, and Bouncy Castle across 7 languages — with PQC readiness, provider patterns, library selection, and migration guidance.
Why this matters: The crypto API your language calls determines how hard your PQC migration will be — JCA sends you down a different path than raw OpenSSL EVP, and getting that provider choice wrong early means rewriting integration code twice.
Cryptographic APIs have grown organically over decades. Each emerged from a specific need: PKCS#11 was created by RSA Labs in 1995 to provide a vendor-neutral interface to hardware security modules. JCA/JCE debuted in 1997 as Sun Microsystems built cryptography into the Java platform with a pluggable provider model. CNG replaced the legacy CryptoAPI in Windows Vista, separating key storage providers from algorithm providers. OpenSSL's EVP API evolved to abstract over multiple algorithm implementations, with v3.x adding a loadable provider system.
These APIs are not interchangeable — they reflect different design philosophies, security models, and deployment targets. Understanding their relationships helps you choose correctly and design for crypto agility.
Related Resources
Products shown here are a representative selection — not an exhaustive list. For the full vendor landscape with PQC readiness status, visit the Tools & Products tab in this module or browse the Migrate catalog →
Check off all sections and mark this reading done.
Related modules
- Stateful Hash SignaturesSame track · Software Infrastructure · Same migration phase
- SLH-DSA: Stateless Hash SignaturesSame track · Software Infrastructure · Same migration phase
- Merkle Tree CertificatesSame track · Software Infrastructure
- Operating System & Platform Crypto PQCSame track · Software Infrastructure
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.