added Comp KEM

Author: dghgit

docs/releasenotes.html

@@ -144,6 +144,7 @@ <h3>2.2.3 Additional Features and Functionality</h3>
 <li>Initial Owl augmented PAKE in the new org.bouncycastle.crypto.agreement.owl package — an academic protocol (Hao, Bag, Chen, Lopez 2024) that extends J-PAKE with explicit user-registration and key-confirmation phases. Lightweight implementation supports the four-pass authentication exchange (OwlClient / OwlServer with OwlAuthenticationInitiate / OwlAuthenticationServerResponse / OwlAuthenticationFinish payloads), the initial user-registration exchange (OwlClientRegistration / OwlServerRegistration with OwlInitialRegistration / OwlFinishRegistration payloads), and optional explicit key-confirmation (OwlKeyConfirmation, both directions). Schnorr zero-knowledge proofs follow RFC 8235 over the OwlCurve elliptic-curve groups (OwlCurves.NIST_P256 supplied; OwlCurve constructor accepts any short-Weierstrass curve), and the shared primitives — Schnorr ZKP creation / validation, public-key validation, MAC-tag computation, transcript hashing — live in OwlUtil. Owl is not (yet) an IETF standard; users wanting a standardised PAKE should prefer the existing J-PAKE (org.bouncycastle.crypto.agreement.jpake / .ecjpake) or stronger asymmetric PAKEs. See misc/.../crypto/examples/OwlExample.java for a worked client+server exchange (PR #2168).</li>
 <li>RFC 9690 "Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS)" support (obsoletes RFC 5990). RSA-KEM key transport now flows through the RFC 9629 KEMRecipientInfo pipeline already in place for ML-KEM / NTRU: the CMS layer was wired for the ISO 18033-2 id-kem-rsa AlgorithmIdentifier (1.0.18033.2.2.4) on the wrap and unwrap sides via JceKEMRecipientInfoGenerator / JceCMSKEMKeyWrapper / JceCMSKEMKeyUnwrapper, but the JCE Cipher service it looked up by name (RSA-KTS-KEM-KWS) was not registered. A new org.bouncycastle.jcajce.provider.asymmetric.rsa.RSAKEMCipherSpi (registered as Cipher.RSA-KTS-KEM-KWS, with Alg.Alias entries against ISOIECObjectIdentifiers.id_kem_rsa) closes the gap: WRAP_MODE performs the ISO 18033-2 RSA encapsulation, applies the KTSParameterSpec-supplied KDF (KDF2 / KDF3 / HKDF, per RFC 9690 §3.2 and §4) to the shared secret with the CMSORIforKEMOtherInfo bytes as the otherInfo / info input, and AES-Wraps the CEK under the derived KEK; UNWRAP_MODE is the symmetric inverse. The RFC 9690 mandatory-to-implement combination (KDF3-SHA-256 + AES-128-WRAP) plus the KDF2-SHA-256, KDF3-SHA-512 and HKDF-SHA-256 variants and AES-128/192/256-WRAP are exercised by new round-trip tests in pkix NewEnvelopedDataTest.</li>
 <li>RFC 9709 "Encryption Key Derivation in the Cryptographic Message Syntax (CMS) Using HKDF with SHA-256" interoperates with the new RFC 9690 KEM recipients: the existing id-alg-cek-hkdf-sha256 (1.2.840.113549.1.9.16.3.31) outer-wrap (opt-in on JceCMSContentEncryptorBuilder via setEnableSha256HKdf(true)) drives CMS_CEK_HKDF_SHA256(IKM, info = DER(inner contentEncryptionAlgorithm)) with the fixed salt "The Cryptographic Message Syntax" to derive the effective CEK from the recipient-delivered IKM, defending against the algorithm-substitution downgrade described in RFC 9709 §1. The recipient-side HKDF derivation (in EnvelopedDataHelper.getJceKey(AlgorithmIdentifier, GenericKey)) now triggers for KEM recipients as well as KeyTrans, KEK and KeyAgree recipients — a new NewEnvelopedDataTest case exercises RSA-KEM (RFC 9690, KDF3-SHA-256 + AES-128-WRAP) layered with the id-alg-cek-hkdf-sha256 content wrap end-to-end.</li>
+<li>Experimental support for Composite ML-KEM (draft-ietf-lamps-pq-composite-kem), which pairs ML-KEM with a traditional KEM (RSA-OAEP / ECDH / X25519 / X448) so the derived secret stays secure while either component does, with the KEM combiner ss = SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Label) of section 3.4. The BC provider registers each of the twelve composite parameter sets — under both its algorithm name (e.g. MLKEM768-ECDH-P256-SHA3-256) and OID — as a KeyPairGenerator (producing org.bouncycastle.jcajce.CompositePublicKey / CompositePrivateKey pairs whose components are the ML-KEM key followed by the traditional key), a KeyGenerator that encapsulates and decapsulates via KEMGenerateSpec / KEMExtractSpec, and a KeyFactory for X.509 / PKCS#8 keys. Verified against the draft Appendix F test vectors.</li>
 </ul>
 
 <a id="r1rv84"><h3>2.2.1 Version</h3></a>