Repository navigation
Please add support of PreHash-MLDSA #2198
Description
Activity
Only SHA512 is defined for this at the moment. Can you tell we what you are trying to do?
-
Support of hash value instead raw data as input:
One of the main purposes of Pre-Hash MLDSA is to allow the application to compute the hash value itself. This is useful since the application may do not the access to the original raw data. -
Support of hash algoroithms other than SHA512:
NIST FIPS-206 does not limit the hash algorithms to SHA512. As in Section "5.4. Pre-Hash ML-DSA", at least three algorithms SHA256, SHA512 and SHAKE256 are listed.
-
Two minor quibbles. On 1, are you sure you can't use external-mu? Pre-hash's only real use case now is for people who do not have access to the public key. On 2, there are no object identifiers for the other variants, it's also questionable that SHA-256 should be used in this way.
I'm really not sure about this one...
On 1: do you have example code for this?
On 2: the object identifiers shall be the same for the hash algorithms, at least for the sha256, sha512 and shake256 (as in FIPS 204).See
With 2, it's not those object identifiers I'm talking about, there's none for the actual signature mechanisms, as in id-hash-ml-dsa-44-with-sha512 it's not really enough just to be able to create a signature, you have to be able to "tag it" in some way so people can understand it.
The signature with mu as intermediate step is still a Pure-MLDSA signature. As you mentioned, the application needs to know the public key.
Pre-Hash ML-DSA will be used where the application is free to choose the hash algorithm, and it just needs to compute the raw hash value (without other input e.g. ctx and public key). I know there is still no OID for combinations e.g. Pre-Hash ML-DSA with SHAKE256, but in many cases, there are other ways to identify the algorithm.
As I understand, the "core" and "prov" modules provide the basic capabilities, many algorithms without known OID are also supported.
Since the MLDSAEngine is not public, it is not possible to implement this feature outside BC. So please consider adding this feature in BC.
I second this request. There is plenty of useful reason to allow this, ranging from obvious (no need for the actual data or any other information or know-how), but also practical ones like that it fits into pre-existing infrastructure... APIs that expect sending digestAlgorithm values can still be used, external-mu is new concept and that puts expectations on the client side.
Current lack of algorithm specifications should not be an issue and if written correctly it could be one size fits all when all of that is added later in the future.
You are already preselecting the digester and therefore OID from key params anyways.
SignatureSpi will probably need new alias for what is essentially NONEwith* variation of this algorithm.
If I understand correctly, in this case you're talking about the ability to sign a passed in hash aren't you?
If I understand correctly, in this case you're talking about the ability to sign a passed in hash aren't you?
Yes.
This I can probably (safely) do. I'm not sure how I'll manage the JCA provider, I'll get something working for the low-level API first.
Reacted by Lijun Liao, PhD and hlavnicka-sefira- added a commit that references this issue
on May 4, 2026 Okay, this is now available on https://www.bouncycastle.org/betas - there's a few lines in https://github.com/bcgit/bc-java/blob/main/docs/releasenotes.html to describe how it's used. Let us know how it goes.
It appears to accept only SHA-512 hash values. Could you generalize it to support additional hash algorithms?
When they're standardized with OIDs. At the moment there's no parameter definitions for these.
Closing as complete for now. We'll watch out for OIDs in the meanwhile.
In the current version (1.82 or the latest github branch main), the class HashMLDSASigner accepts only the raw data as input.
Please either extend the class HashMLDSASigner, or better create a new class which accepts the hash value (byte[]) and hash algorithm OID (byte[]) as input. This allows the external application to compute the hash value by itself.