Bouncy Castle Rust Roadmap

Roadmap

Bouncy Castle Rust is at 0.1.3alpha (see 0.1.3alpha Is Released), with 0.1.4alpha in progress on the release/0.1.4alpha branch. The alpha releases focus on the design of the public trait and error type system in the core sub-crate (bouncycastle-core): algorithms are reached through key objects that hand out workers, every sensitive buffer is typed KeyMaterial, and what is only safe when composed correctly lives under hazmat.

Released so far (0.1.3alpha):

• Hex and Base64 (constant-time)
• SHA-2 (including SHA-512/224 and SHA-512/256), SHA-3 and SHAKE, and the SP 800-185 functions cSHAKE, KMAC, TupleHash and ParallelHash
• SM3
• HMAC and HKDF, generic over the hash
• AES (bit-sliced, constant-time) in ECB, CBC, CFB, CFB8, CTR, CCM and GCM, with CMAC and GMAC, on a cipher crate of modes generic over the block cipher
• Ascon-AEAD128, Ascon-Hash256, Ascon-XOF128 and Ascon-CXOF128
• The NIST HashDRBG random number generator
• ML-DSA and ML-KEM, each in a standard and a low-memory implementation
• Provider-style factory objects, and a command-line interface for all of the above

On the 0.1.4alpha branch, or in review for it:

• Block ciphers: ARIA, Camellia, SM4 and Triple-DES, constant-time and table-free, under the same modes as AES; AES, ARIA, Camellia and SM4 key wrap (KW and KWP) and TDES TKW
• ChaCha20, Poly1305 and ChaCha20-Poly1305
• Signatures: ECDSA over P-256, P-384, P-521, secp256k1 and the brainpool curves, on a constant-time ec crate; SM2; RSASSA-PKCS1-v1_5 and RSASSA-PSS
• Key establishment: ECC CDH over the same seven curves with the X9.63 KDF, X25519, RSASVE (SP 800-56B Rev. 2 Section 7.2.1, RSA secret-value encapsulation as a KEM over RSA-2048 to 8192), and ML-KEM with its shared secret derived through HKDF; the key-agreement and KEM operations move onto the key objects as signing did
• BLAKE2b, BLAKE2s and BLAKE3

Next up:

• Ed25519 and Ed448; X448
• RSA key transport
• Password hashing: PBKDF2, Scrypt, Argon2
• Hybrids / composites of the above
• no_std for the core crates, and feature granularity

Stretch goals for 1.0 release:

• SLH-DSA
• LMS/HSS, XMSS -- implementing the verifier is probably higher priority than a signer since signers should probably use HSMs)
• Merkle Tree Certificates
• HQC, FrodoKEM

After that, we'll tackle in some kind of order (depending on public interest and funding):

• PKIX (DER, X.509, CMS, CMP)
• integration with openssl and rustls for TLS 1.3
• PKCS#11 passthrough -- ie high-level APIs work the same regardless of whether it's using local software keys and crypto, or hardware-backed crypto.
• Softening the #[forbid(unsafe) stance to be able to make use of hardware acceleration such as AVX, AESNI, SHA2. Will require some formal methods work.
• JWT & CWT
• Refining the library's build system (build and release packaging, etc)

FIPS Certification

Bouncy Castle Rust is built to be FIPS certified, so as soon as we have a stable set of cryptographic algorithms, we will be first obtaining an ACVP certificate and then beginning the (long) process of obtaining a CMVP certificate. Hopefully we will be in a position to begin this by the end of 2026, but it will depend on our progress at completing the cryptographic algorithms.

Community feedback is most welcome!

As this is an alpha release, we're eagerly looking for feedback from the community. We would especially like feedback on the following areas:

• Public API ergonomics and granularity of exposed functionality.
• Certification / compliance concerns.
• Prioritization of roadmap items above.

You can reach us at office@bouncycastle.org or mike@bouncycastle.org.

Sincerely, Mike Ounsworth Lead Maintainer of BC-Rust, on behalf of the Legion of the Bouncy Castle and the entire Bouncy Castle community