Please add support of PreHash-MLDSA

[xipki]

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.

[dghgit]

Only SHA512 is defined for this at the moment. Can you tell we what you are trying to do?

[xipki]

1. 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.

2. 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.

[dghgit]

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...

[xipki]

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).

[dghgit]

See

bc-java/prov/src/test/java/org/bouncycastle/pqc/jcajce/provider/test/MLDSATest.java

Line 482 in 04ffb14

public void testMLDSARandomMsgAndMuSig()

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.

[xipki]

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.

[hlavnicka-sefira]

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.

bc-java/core/src/main/java/org/bouncycastle/pqc/crypto/mldsa/HashMLDSASigner.java

Lines 173 to 182 in d716d77

	private static Digest createDigest(MLDSAParameters parameters)
	{
	switch (parameters.getType())
	{
	case MLDSAParameters.TYPE_PURE:
	case MLDSAParameters.TYPE_SHA2_512:
	return new SHA512Digest();
	default:
	throw new IllegalArgumentException("unknown parameters type");
	}

SignatureSpi will probably need new alias for what is essentially NONEwith* variation of this algorithm.

[dghgit]

If I understand correctly, in this case you're talking about the ability to sign a passed in hash aren't you?

[xipki]

If I understand correctly, in this case you're talking about the ability to sign a passed in hash aren't you?

Yes.

[dghgit]

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.

[dghgit]

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.

[xipki]

It appears to accept only SHA-512 hash values. Could you generalize it to support additional hash algorithms?