Added support for ECKA-EG, relates to github #790.

Author: dghgit

docs/releasenotes.html

@@ -49,6 +49,7 @@ <h3>2.1.2 Defects Fixed</h3>
 <li>JceOpenSSLPKCS8DecryptorProviderBuilder cast the PBES2 key-derivation-function parameters blind to PBKDF2Params, so an EncryptedPrivateKeyInfo whose KDF inside PBES2 was scrypt (RFC 7914, e.g. anything produced by "openssl pkcs8 -topk8 -scrypt") failed to decrypt with "DLSequence cannot be cast to PBKDF2Params". The builder now dispatches on the KDF algorithm OID: id-PBKDF2 takes the existing PBKDF2 path, id-scrypt parses the parameters as ScryptParams and derives the key via SCrypt.generate (the password is encoded as UTF-8 to match OpenSSL's raw-bytes treatment). PBKDF2-based PBES2, PKCS#5 PBES1 and PKCS#12 PBE paths are unchanged (issue #400).</li>
 <li>RFC3280CertPathUtilities.processCRLB2 (in both prov and pkix) emitted an opaque AnnotatedException "No match for certificate CRL issuing distribution point name to cRLIssuer CRL distribution point." when the CRL's issuingDistributionPoint did not match the cert's CRL distribution point names, with no way for an operator to tell which CRL had been returned for which DP. The message now appends both name lists, e.g. ". cert DP names: [6: http://crl3.example/foo.crl, 6: http://crl4.example/foo.crl]; CRL IDP names: [6: http://crl4.example/bar.crl]", letting the cause of the mismatch be diagnosed without re-running with extra logging. Existing assertion sites in NistCertPathTest / NistCertPathTest2 / PKITSTest were updated to use prefix-matching against the original message (issue #800).</li>
 <li>JceInputDecryptorProviderBuilder previously assumed the supplied AlgorithmIdentifier parameters were either an ASN1OctetString (raw IV) or GOST28147Parameters, so init() failed with "DLSequence cannot be cast to ASN1ObjectIdentifier" (via the GOST fallback) on an AES-GCM (or AES-CCM) AlgorithmIdentifier carrying GCMParameters / CCMParameters. The builder now dispatches on the algorithm OID: id-aes{128,192,256}-GCM and id-aes{128,192,256}-CCM parse the parameters as GCMParameters / CCMParameters and init the cipher via GCMParameterSpec(icvLen*8, nonce); the existing IV and GOST paths are unchanged (issue #1510).</li>
+<li>CMS EnvelopedData with a BSI TR-03111 ECKA-EG-X963KDF key agreement (BSIObjectIdentifiers.ecka_eg_X963kdf_SHA1/SHA224/SHA256/SHA384/SHA512/RIPEMD160) failed both encode and decode: JceKeyAgreeRecipientInfoGenerator threw "Unknown key agreement algorithm" on generate, and JceKeyAgreeRecipient's parallel branch silently fell through to a null UserKeyingMaterialSpec, producing the wrong shared secret and "checksum failed" on the AES key unwrap. The underlying agreement (ECDHBasicAgreement + KDF2BytesGenerator) is structurally identical to dhSinglePass_stdDH_*kdf_scheme, and BSI TR-03109-3 / ICAO 9303-11 — the canonical consumers of ECKA-EG-in-CMS — specify the RFC 5753 ECC-CMS-SharedInfo format for the KDF input. The six BSI ecka_eg_X963kdf_* OIDs have been added to the EC dispatch table in CMSUtils so both encode and decode route through the existing RFC 5753 KeyMaterialGenerator (issue #790).</li>
 <li>BLS12_381Aggregation.aggregateVerifyHashed previously fed the per-signer (pk_i, H(msg_i)) pairs straight into the multi-pairing, omitting the per-message public-key aggregation and identity-rejection step required by draft-irtf-cfrg-bls-signature §2.9 lines 12-13. An attacker who controlled pk_a and pk_b = -pk_a (each with a valid PoP, since they hold both secret keys) could publish an aggregate over (pk_a, m), (pk_b, m), (pk_c, m') whose pk_a / pk_b contributions cancelled in the pairing equation, reducing it to a check of pk_c on m' while the aggregate still ostensibly claimed contributions from pk_a and pk_b. BLS12_381BasicScheme.aggregateVerify pre-screened by rejecting duplicate messages and BLS12_381MessageAugmentation folded the public key into the hash input so the spec grouping was trivial, but BLS12_381ProofOfPossession.aggregateVerify took the unmodified helper path. The shared helper now groups signers by hashed message, sums the public keys per group, and rejects the aggregate when any per-group key equals the G1 identity (the spec form for §2.9); all three schemes inherit the check.</li>
 </ul>
 <h3>2.2.3 Additional Features and Functionality</h3>

pkix/src/main/java/org/bouncycastle/cms/CMSUtils.java

@@ -29,6 +29,7 @@
 import org.bouncycastle.asn1.DERSet;
 import org.bouncycastle.asn1.DERTaggedObject;
 import org.bouncycastle.asn1.DLSet;
+import org.bouncycastle.asn1.bsi.BSIObjectIdentifiers;
 import org.bouncycastle.asn1.cms.AttributeTable;
 import org.bouncycastle.asn1.cms.CMSObjectIdentifiers;
 import org.bouncycastle.asn1.cms.ContentInfo;
@@ -92,6 +93,18 @@ class CMSUtils
         ecAlgs.add(PKCSObjectIdentifiers.dhSinglePass_stdDH_hkdf_sha384_scheme);
         ecAlgs.add(PKCSObjectIdentifiers.dhSinglePass_stdDH_hkdf_sha512_scheme);
 
+        // BSI TR-03111 ECKA-EG with X9.63 KDF. Structurally identical to
+        // dhSinglePass_stdDH_*kdf_scheme (ECDH + X9.63 KDF + RFC 5753
+        // ECC-CMS-SharedInfo per BSI TR-03109-3 / ICAO 9303-11); dispatch
+        // through the same EC code path so the RFC 5753 KDF material is
+        // generated consistently for both encode and decode (issue #790).
+        ecAlgs.add(BSIObjectIdentifiers.ecka_eg_X963kdf_SHA1);
+        ecAlgs.add(BSIObjectIdentifiers.ecka_eg_X963kdf_SHA224);
+        ecAlgs.add(BSIObjectIdentifiers.ecka_eg_X963kdf_SHA256);
+        ecAlgs.add(BSIObjectIdentifiers.ecka_eg_X963kdf_SHA384);
+        ecAlgs.add(BSIObjectIdentifiers.ecka_eg_X963kdf_SHA512);
+        ecAlgs.add(BSIObjectIdentifiers.ecka_eg_X963kdf_RIPEMD160);
+
         gostAlgs.add(CryptoProObjectIdentifiers.gostR3410_2001_CryptoPro_ESDH);
         gostAlgs.add(CryptoProObjectIdentifiers.gostR3410_2001);
         gostAlgs.add(RosstandartObjectIdentifiers.id_tc26_agreement_gost_3410_12_256);

pkix/src/test/java/org/bouncycastle/cms/test/NewEnvelopedDataTest.java

@@ -2164,6 +2164,43 @@ public void testECKeyAgree()
         assertEquals(X9ObjectIdentifiers.prime239v1, recInfo.getOriginator().getOriginatorKey().getAlgorithm().getParameters());
     }
 
+    public void testEckaEgX963Kdf()
+        throws Exception
+    {
+        // Round-trip a CMS EnvelopedData under the BSI TR-03111 ECKA-EG-X963KDF-SHA256
+        // key agreement, wrapping an AES-128 content-encryption key. Closes
+        // github #790 — without the dispatch fix in CMSUtils the encode side throws
+        // "Unknown key agreement algorithm" and the decode side (in pre-2.85 BC)
+        // fell through to a null UserKeyingMaterialSpec, producing the wrong shared
+        // secret and a "checksum failed" InvalidKeyException from the AES key unwrap.
+        ASN1ObjectIdentifier[] kdfs = new ASN1ObjectIdentifier[]{
+            CMSAlgorithm.ECKA_EG_X963KDF_SHA256,
+            CMSAlgorithm.ECKA_EG_X963KDF_SHA384,
+            CMSAlgorithm.ECKA_EG_X963KDF_SHA512
+        };
+        byte[] data = Hex.decode("504b492d4320434d5320456e76656c6f706564446174612053616d706c65");
+
+        for (int i = 0; i != kdfs.length; ++i)
+        {
+            CMSEnvelopedDataGenerator edGen = new CMSEnvelopedDataGenerator();
+
+            edGen.addRecipientInfoGenerator(new JceKeyAgreeRecipientInfoGenerator(kdfs[i],
+                _origEcKP.getPrivate(), _origEcKP.getPublic(),
+                CMSAlgorithm.AES128_WRAP).addRecipient(_reciEcCert).setProvider(BC));
+
+            CMSEnvelopedData ed = edGen.generate(
+                new CMSProcessableByteArray(data),
+                new JceCMSContentEncryptorBuilder(CMSAlgorithm.AES128_CBC).setProvider(BC).build());
+
+            assertEquals(ed.getEncryptionAlgOID(), CMSEnvelopedDataGenerator.AES128_CBC);
+
+            RecipientInformationStore recipients = ed.getRecipientInfos();
+
+            confirmDataReceived(recipients, data, _reciEcCert, _reciEcKP.getPrivate(), BC);
+            confirmNumberRecipients(recipients, 1);
+        }
+    }
+
     public void testFaultyAgreementRecipient()
         throws Exception
     {