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
ML-KEM KeyGenerator, Cipher, KEM and KeyFactory.translateKey now convert ML-KEM keys from other providers via their encodings, with TLS tests for keys supplied ahead of BC, relates to github #2466.
Copy file name to clipboardExpand all lines: CONTRIBUTORS.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -552,3 +552,4 @@ We also wish to acknowledge financial and collaborative support from [CISCO](htt
552
552
- sfeng-c \<https://github.com/sfeng-c\> - initial implementation of the CRMF protocolEncrKey control (RFC 4211 sec. 6.6), with round-trip test coverage (PR #2443).
553
553
- Carsten Hammer \<https://github.com/carstenartur\> - deriving the c6 and c7 constants of the generic RFC 9380 sqrt_ratio calculator from a shared z^c3, saving a modular exponentiation per instance, with tests comparing the stored constants against the direct powers (PR #2455).
554
554
- pyj kor \<pyjkor@gmail.com\> - report of the RFC 5990 RSA-KTS CMS recipient deriving to the keyLength declared in the message rather than the length the key-wrapping algorithm of its data encapsulation mechanism fixes, with the crafted message and the reproduction that showed what the declared length was worth.
555
+
- Will Childs-Klein \<https://github.com/WillChilds-Klein\> - initial implementation of ML-KEM key conversion for BCJSSE when another provider supplies the keys, with the diagnosis and reproduction of the resulting handshake failure (PR #2466).
Copy file name to clipboardExpand all lines: docs/releasenotes.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,6 +59,7 @@ Date: 2026, TBD
59
59
- DSTU7624WrapEngine.unwrap had no bound check on its input and accepted a single block, whose unwrapping is empty, and wrap accepted empty input; unwrap now rejects an input shorter than two blocks or beyond the buffer, and wrap requires at least one block.
60
60
- Cipher.getInstance("DSTU7624/CCM/NoPadding") and the -128/-256/-512 forms generated the generic 12 byte CCM nonce when initialised without parameters, while the OID-registered DSTU 7624 CCM ciphers generate a whole block; the mode-string form now generates a whole-block nonce too.
61
61
- JceKeyAgreeRecipientInfoGenerator created its 1-pass ECMQV ephemeral key pair once per generator rather than once per message, so a generator used for more than one message sent the same ephemeral key in each and derived the same key-encryption key for every recipient each time, withdrawing the ephemeral contribution RFC 5753 sec. 3.2 relies on. The messages were well formed and decrypted correctly. A fresh key pair is now generated for each KeyAgreeRecipientInfo, still shared by all of its recipients.
62
+
- The ML-KEM KeyGenerator (KEMGenerateSpec/KEMExtractSpec), Cipher (wrap/unwrap), javax.crypto.KEM and KeyFactory.translateKey services accepted only BC's own ML-KEM key objects, and the KeyGenerator failed with a ClassCastException at generateKey() rather than at init, so an ML-KEM key from another provider could not be used with BC even though its standard encoding was one BC reads. This broke BCJSSE handshakes over the ML-KEM and hybrid groups whenever another provider ahead of BC decoded the peer's key or generated the ephemeral key pair. A foreign key is now converted from its X.509 or PKCS#8 encoding, with the usual parameter-set checks, and an unusable one is rejected at init (github #2466).
0 commit comments