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 d57ff69
Browse filesBrowse the repository at this point in the historyBrowse files
The BC ML-DSA, ML-KEM and SLH-DSA keys and the BCPQC keys with named parameter sets now implement getParams(), returning a NamedParameterSpec naming the parameter set on Java 11 and later as the JDK's own keys do, and the BCPQC MAYO, SDitH, SNOVA and NTRU+ KeyPairGenerators now accept a NamedParameterSpec, which they had refused whatever its case, relates to github #2467.
Copy file name to clipboardExpand all lines: docs/releasenotes.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,6 +65,8 @@ Date: 2026, TBD
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
67
68
+
- 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
+
68
70
### 2.1.3 Additional Features and Functionality
69
71
70
72
- The CRMF certificate request message controls now include the RFC 4211 sec. 6.6 protocolEncrKey control, which names the key a CA is to encrypt its response with: org.bouncycastle.cert.crmf.ProtocolEncrKeyControl carries the SubjectPublicKeyInfo the control is defined to take, and CertificateRequestMessage.getControl() recognises id-regCtrl-protocolEncrKey alongside the regToken, authenticator and pkiArchiveOptions controls it already returned (github PR #2443).
@@ -82,6 +84,8 @@ Date: 2026, TBD
82
84
83
85
- The BCJSSE provider adds an org.bouncycastle.jsse.BCSSLContext interface exposing extended functionality of its SSLContext, obtained with org.bouncycastle.jsse.util.ContextUtil.getBCSSLContext() by way of the new BCSSLSessionContext interface the context's session contexts implement. Its getDefaultParameters(boolean) and getSupportedParameters(boolean) return the context's default and supported parameters as a BCSSLParameters for either client or server mode, including the BC-specific properties, where SSLContext.getDefaultSSLParameters() and getSupportedSSLParameters() report client mode only and cannot carry those properties. A BCSSLContext describes the initialization of the SSLContext it was obtained from, and is not updated if the SSLContext is re-initialized.
84
86
87
+
- 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
+
85
89
### 2.1.4 Additional Notes
86
90
87
91
- 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