New Release: Bouncy Castle Java 1.86

The Bouncy Castle team is pleased to announce the release of Bouncy Castle Java 1.86, bringing significant advances in post-quantum cryptography across the protocol stack, identity-based cryptography for emerging markets, next-generation certificate formats, TLS modernization, and quantum-safe signature schemes for firmware and software signing.

This release expands the library's standards coverage while helping organizations prepare for the next generation of cryptographic security and represents a significant step forward in making advanced cryptographic capabilities accessible through familiar APIs and trusted protocols.

Key Updates

Post-Quantum Key Establishment Across the Protocol Stack

Bouncy Castle 1.86 makes post-quantum and hybrid key encapsulation mechanisms (KEMs) usable throughout the protocols that organizations actually deploy. The release adds RFC 9629 support for CMS/S-MIME recipients, bringing FrodoKEM, Classic McEliece, and Composite ML-KEM key material directly into encrypted messages and authenticated envelopes. HPKE gains support for ML-KEM variants and the X-Wing hybrid mechanism.

In FIPS mode, BCJSSE treats ML-KEM named groups as approved and enables SecP/ML-KEM hybrids by default. All KEMs—including FrodoKEM, Classic McEliece, NTRU LPRime, NTRU+, SMAUG-T, and ML-KEM—are now reachable through the standard javax.crypto.KEM API, eliminating vendor lock-in and making quantum-resistant cryptography a practical choice for production deployments protecting long-lived data against harvest-now-decrypt-later attacks.

SM9 Identity-Based Cryptography for Regulated Markets

Few general-purpose cryptographic libraries offer complete support for SM9, and fewer still implement all four cryptographic schemes defined in GM/T 0044-2016. Bouncy Castle 1.86 delivers the complete suite—digital signature, key encapsulation, public-key encryption, and two-round key exchange—built on R-ate pairings over a 256-bit Barreto-Naehrig curve.

The implementation removes the need for public key infrastructure by deriving each user's key from their identity through a trusted Key Generation Centre. The provider exposes SM9 through standard JCA interfaces (Signature.SM9, Cipher.SM9, KeyGenerator.SM9-KEM, KeyAgreement.SM9), and message syntax OIDs from GM/T 0080 and GM/T 0081 are provided.

This opens access to China and other regulated markets where GM/T algorithms are mandated across finance, telecommunications, government, and critical infrastructure sectors, while offering a certificate-free encryption and signing model for IoT and secure-messaging deployments.

Next-Generation Certificate Formats: C509 and Merkle Tree Certificates

Bouncy Castle 1.86 embraces emerging certificate standards to serve constrained devices and post-quantum deployments. C509 certificates (draft-ietf-cose-cbor-encoded-cert-20) use CBOR encoding to achieve dramatic size reductions compared to DER X.509, making certificates practical for IoT platforms such as EDHOC/OSCORE, LwM2M, and smart metering. The library includes a complete deterministic CBOR layer, lightweight and JCA verifiers, support for C509 certification requests, templates, private-key structures, and COSE_C509 formats.

Merkle Tree Certificate support now generates inclusion and consistency proofs, enabling certificate authorities, transparency logs, and WebPKI operators to build large post-quantum-safe certificate chains without implementing their own tree logic. New KeyPurposeId constants for RFC 9509 (5G), RFC 6187 (SSH), and RFC 4556 (Kerberos) round out PKI feature coverage for modern applications.

Modernized TLS: OCSP Stapling and RFC 9850 Key Logging

Migration to TLS 1.3 previously meant losing Online Certificate Status Protocol (OCSP) stapling support—a privacy-preserving revocation mechanism. Bouncy Castle 1.86 restores this capability, enabling both client- and server-side stapling in TLS 1.3 (RFC 8446 sec. 4.4.2.1) through the org.bouncycastle.tls API.

BCJSSE, the JCA provider, now offers server-side stapling for both TLS 1.2 and 1.3, automatically fetching, caching, and relaying OCSP responses under the system properties that Sun JSSE uses.

For security teams and QA engineers, the release includes RFC 9850 SSLKEYLOGFILE support through a TlsKeyLog interface that covers both the (D)TLS API and BCJSSE. In order to ensure full transparency, and to ensure this cannot be accidentally enabled, support is delivered in a separate bctls-klog artifact which must be used instead of the regular bctls API.

Hash-Based Signatures Promoted to Core Cryptography

Stateful hash-based signatures—LMS/HSS (RFC 8554) and XMSS/XMSS^MT (RFC 8391, NIST SP 800-208)—are the schemes named by CNSA 2.0 and SP 800-208 for firmware and software signing. Bouncy Castle 1.86 graduates these algorithms from the experimental namespace into org.bouncycastle.crypto alongside ML-KEM, ML-DSA, and SLH-DSA, with full Java Cryptography Architecture (JCA) support in the main BC provider. RFC 9802 X.509 OID support enables standard key material interchange.

State handling is hardened by cross-checking a key's stored index against its tree state on load and refusing to sign with exhausted or destroyed keys until their one-time index is spent. This meets the mandate for quantum-safe firmware signing while reducing the risk of one-time-key reuse and simplifying compliance evidence for defense, government, and embedded-systems organizations.

Fixed CVEs

Fixes for the following CVEs:

• CVE-2026-17507 - MLS membership checks compare a uint32 leaf_index as signed, admitting an out-of-range sender.
• CVE-2026-17508 - Password-based KDF cost parameters honoured unbounded from untrusted input across the remaining PBE entry points.
• CVE-2026-18036 - NTRU leaks private key information by reducing secret values with a non-constant-time integer division.
• CVE-2026-18040 - HQC leaks private key information through secret-indexed GF(2^8) tables and a secret-dependent fixed-weight sampler.
• CVE-2026-71885 - MLS X.509 credential not bound to the LeafNode signature key.
• CVE-2026-71886 - OpenPGP certification accepted from a subkey without certification authority.
• CVE-2026-71887 - OpenPGP data signature accepted from a signing subkey without cross-certification.
• CVE-2026-71888 - CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent.
• CVE-2026-71889 - PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate.
• CVE-2026-71890 - MLS external commit can remove an arbitrary group member.
• CVE-2026-71891 - BLS12-381 key validation accepts a public key built on a foreign curve.
• CVE-2026-71892 - CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys.
• CVE-2026-85515 - OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check.

Release Notes

For the complete list of added features, fixed security issues, and defects, see:

• Bouncy Castle Java 1.86 release notes

Download

Bouncy Castle Java 1.86 is now available on Maven Central and on bouncycastle.org/download. Software Bill of Materials (BOM) files are available on Maven Central.

Download Java