Hi Sorin, Thanks for your interest in this issue.
> On Oct 29, 2026, at 09:26, Sorin Basca <[email protected]> wrote: > > Hello, > > We would like to inquire about picking up the work on JDK-8384521. We > see it remains open and that the earlier exploration in PR #23934 was > abandoned due to its large scope. PR #23934 was automatically closed by our bot because of low traffic. I already have a code change for JDK-8384521, which introduced the public API described there, and the implementation is just a thin shim on PR #23934. It has not been posted because PR #23934 is not integrated yet. > > We would like to propose that we move JDK-8384521 forward with a > focused scope. This would include the following: > > 1. Adding MLDSAParameterSpec.ExternalMu and MLDSAParameterSpec.Context > for configuring the Signature instances. > > 2. Providing a standard MessageDigest pre-initialized with the public > key and context to stream large messages and produce the 64 byte mu. > For this we will add MLDSAParameterSpec.DigestBuilder and > MLDSAExternalMuDigestSpi. The second part of your proposal is too focused on this single usage and does not seem to warrant an API, let alone an API/SPI pair that needs to be implemented in providers. Calculating it, as you said below, is a little delicate but still doable. IMHO, the only tricky part is to find the raw public key to calculate tr if one only has the X.509 getEncoded() value of the public key. We know there are only 3 standard parameter sets for ML-DSA, so the extraction is merely comparing the first few bytes of the public key X.509 encoding to 3 known byte sequences and the rest (if the length is correct) is the raw public key. Thank you for offering to contribute but we have already completed most of this work. We will continue. Thanks, Weijun > > 3. Complete implementation in the SUN provider. > > We are aware that mu can be computed by hand with > MessageDigest.getInstance("SHAKE256-512") running over tr || 0x00 || > len(ctx) || ctx || M. However, this is error-prone as callers need to > perform several steps and a mistake would produce a signature that > fails to verify. The typed API would allow providers that already > compute mu natively to plug in their own implementation. > > We are raising this because we have encountered a critical requirement > for signing with an externally computed message representative mu when > deploying ML-DSA across hardware and isolated cryptographic modules. > > We have a clean, tested prototype ready and would like to know if you > would welcome our help in driving JDK-8384521 forward and whether this > scoped design would meet your expectations. > > Many thanks, > Sorin Basca (on behalf of the Google Java Platform & ISE Crypto teams)
