You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 451ca8b
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/releasenotes.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -64,6 +64,9 @@ Date: 2026, TBD
64
64
- The raw JCA provider bounded the PBKDF2 iteration count taken from an encoding (org.bouncycastle.pbe.max_iteration_count, default 10,000,000) but not the counts of the legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families beside it. Their AlgorithmParameters (PKCS12PBE and its OID aliases, PBKDF1) accepted any count, narrowing one beyond the int range with intValue() so that 2^32 arrived as 0, and every Cipher, Mac and SecretKeyFactory derivation ran with whatever count it was given - including a count decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected key with BC. As these schemes carry the count in unauthenticated parameters and derive before anything can be checked, a supplied blob could hold a derivation for tens of minutes. The parameter parse now rejects a negative, beyond-int or over-limit count, and the derivations reject a negative or over-limit count, under the same property as PBKDF2. The PKCS#12 key store derives through the same code, so a org.bouncycastle.pkcs12.max_it_count raised above 10,000,000 now needs org.bouncycastle.pbe.max_iteration_count raised with it.
65
65
- The ML-DSA public key constructor taking rho and t1 separately checked only for null, so an ML-DSA SubjectPublicKeyInfo in the SEQUENCE { OCTET STRING rho, OCTET STRING t1 } form with a t1 of the wrong length was accepted by PublicKeyFactory and the JCA KeyFactory, unlike the same key in the standard raw encoding. The component constructors for ML-DSA private keys (rho, K, tr, s1, s2, t0, t1, seed) and SLH-DSA private keys (skSeed, prf, pkSeed, pkRoot) likewise accepted components of any length. All three now reject a component whose length does not match the parameter set with an IllegalArgumentException.
66
66
- The light-weight CryptoProWrapEngine (RFC 4357 sec. 6.3) diversified the key encryption key in the caller's own array, so after init the KeyParameter it was given held the diversified key, and initialising again with the same parameters - to unwrap what had just been wrapped, say - diversified it a second time and used a different key. It also failed with a NullPointerException when given no S-box, although init has a branch for that case. It now diversifies a copy, and given no S-box uses the GOST 28147 engine's default S-box for the diversification, the one the wrap itself then uses. The provider's GOST 28147 key wrap ciphers were unaffected, as they always supply an S-box and build a new KeyParameter on every init.
67
+
- A UserKeyingMaterialSpec carrying a KDF salt was accepted by every KeyAgreement that takes one, although only the HKDF based agreements (X25519withSHA256HKDF, X448withSHA512HKDF and the RFC 8418 XDHwithSHA\*HKDF schemes) use a salt: the X9.63 and concatenation KDF agreements for EC, DH and XDH, and the ECGOST VKO agreements, derived their key without it and gave no sign of having done so. A salt given to any agreement whose KDF is not HKDF is now refused at init with an InvalidAlgorithmParameterException.
68
+
- The light-weight ConcatenationKDFGenerator (NIST SP 800-56A concatenation KDF) threw NullPointerException from generateBytes when its KDFParameters carried no OtherInfo, although KDFParameters documents the additional input as optional and KDF1 and KDF2 already treated a null one as empty. Every provider key agreement over it that was given no user keying material hit it: ECCDHwithSHA\*CKDF initialised without a UserKeyingMaterialSpec, and ECCDHUwithSHA\*CKDF, ECMQVwithSHA\*CKDF, DHUwithSHA\*CKDF and MQVwithSHA\*CKDF initialised with a DHUParameterSpec or MQVParameterSpec that carried none. The XDH agreements were unaffected, as they substituted an empty value. A null OtherInfo now derives what an empty one does, H(counter || Z), and KDFParameters refuses a null shared secret at construction rather than leaving it to fail inside the KDF.
69
+
- The PKCS12-DEF-AES256-AES128 and PKCS12-DEF-AES256-AES128-GCM KeyStores performed their key protection and MAC operations with the BC provider, rather than through the default JCA provider search that the other PKCS12-DEF stores use, as their implementations were built with the BC helper. They now use the default search, and the PKCS12-AES256-AES128 and PKCS12-AES256-AES128-GCM KeyStores, which had been registered to those same implementations, are now registered to the BC ones.
67
70
68
71
- The BCPQC MAYO, SDitH, SNOVA and NTRU+ KeyPairGenerators refused every java.security.spec.NamedParameterSpec with InvalidAlgorithmParameterException, whatever parameter set it named and in whatever case: they lower-cased the name and then looked it up in a table of upper-case names. The name is now upper-cased, so NamedParameterSpec("MAYO-1") and NamedParameterSpec("mayo-1") both select MAYO-1, as the other BCPQC families already allowed. The generators' own ParameterSpec classes were never affected.
69
72
@@ -86,6 +89,8 @@ Date: 2026, TBD
86
89
87
90
- The BC provider's ML-DSA, ML-KEM and SLH-DSA keys now implement getParams(), which keys inherit from java.security.AsymmetricKey from Java 22, returning a java.security.spec.NamedParameterSpec naming the parameter set (for example "ML-DSA-65") on Java 11 and later, and null before. The JDK's own ML-DSA and ML-KEM keys return only the family name, "ML-DSA" or "ML-KEM", from getAlgorithm() and report the parameter set this way, so comparing getParams() rather than getAlgorithm() now identifies the parameter set whichever provider made the key. The BCPQC provider's keys do the same for every family with named parameter sets - AIMer, BIKE, FAEST, Falcon, HAETAE, HQC, MAYO, MQOM, NTRU, NTRU+, NTRU LPRime, Streamlined NTRU Prime, QR-UOV, SABER, SDitH, SMAUG-T, SNOVA, SQIsign and UOV - with the name their ParameterSpec reports, which the family's KeyPairGenerator accepts back. getAlgorithm() on BC and BCPQC keys is unchanged (github #2467).
88
91
92
+
- The provider adds ECDHwithSHA256HKDF, ECDHwithSHA384HKDF and ECDHwithSHA512HKDF KeyAgreement algorithms: ECDH followed by HKDF (RFC 5869), the counterparts for elliptic curve keys of the XDHwithSHA\*HKDF agreements used for the RFC 8418 dhSinglePass-stdDH-hkdf schemes. As with those, a UserKeyingMaterialSpec supplies the HKDF info and, optionally, its salt. They are registered by name only; the RFC 8418 scheme object identifiers remain registered to the XDH agreements.
93
+
89
94
### 2.1.4 Additional Notes
90
95
91
96
- The sources and javadoc jars of the Ant-built distributions (jdk14, jdk15to18 and jdk13) no longer carry test material. Each module's javadoc target copies the package documentation it needs - org/bouncycastle/<area>/**/*.html - back into the module source directory that has already been compiled from, and zip-src zips that directory afterwards, so every test package's package.html arrived in the sources jar by that route; javadoc-util additionally copied org/bouncycastle/asn1/isismtt/**/*.java, which put test classes into the bcutil javadoc as generated pages, and javadoc-pg deliberately copied the gpg and bcpg test sources in order to document them. Separately the source copies excluded test material only one directory deep and only for *.java, because Ant reads ** as an any-depth wildcard just where it is a whole path segment, so anything nested further or with another extension - the PEM certificate fixtures under org/bouncycastle/est/test/san corrected in 1.86, and an ICAO master list under org/bouncycastle/asn1/icao/test - went through. The source and javadoc copies of every module now exclude test directories at any depth, and javadoc-pg no longer documents the test packages. org.bouncycastle.util.test is unaffected and still ships in the bcprov binary, sources and javadoc jars, as it does from the Gradle build: it is the SimpleTest framework the light-weight API's own test classes are written against, not test material of the distribution. No binary changes - the classes and resources of every Ant-built jar are identical to those of the 1.86 release - and the Gradle-built jdk18on artifacts never carried any of this.
0 commit comments