proposal: crypto/mldsa: Verify API can't verify signatures created with crypto.MLDSAMu

[gojuukaze]

Proposal Details

In the crypto/mldsa package (go 1.27), PrivateKey.Sign accepts crypto.SignerOpts. It allows signing an external μ message by checking opts.HashFunc() == crypto.MLDSAMu:

func (sk *PrivateKey) Sign(_ io.Reader, message []byte, opts crypto.SignerOpts) (signature []byte, err error) {
    // ...
    switch opts.HashFunc() {
    case 0:
        // ... directly-signed message
    case crypto.MLDSAMu:
        return mldsa.SignExternalMu(&sk.k, message)
    default:
        return nil, errInvalidSignerOpts
    }
}

However, the public Verify API only accepts *Options instead of an interface like crypto.SignerOpts or a mechanism to support crypto.MLDSAMu.

func Verify(pk *PublicKey, message []byte, signature []byte, opts *Options) error {
    // ...
    return mldsa.Verify(&pk.p, message, signature, opts.Context)
}

Because Verify only passes opts.Context into the internal mldsa.Verify, there is currently no way to verify a signature that was generated using crypto.MLDSAMu. The underlying mldsa.VerifyExternalMu functionality is completely trapped and unexported to consumers of the public crypto/mldsa package.

Proposal:

Change the opts parameter of Verify to support crypto.MLDSAMu, or export a dedicated VerifyExternalMu function.

[gabyhelp]

Related Issues

• proposal: crypto/mldsa: add MuHash #79533
• crypto/mldsa: new package #77626 (closed)
• crypto/x509,crypto/tls: add ML-DSA support #78888 (closed)
• proposal: crypto/ecdsa: VerifyStrict for signature malleability #71610
• crypto/ecdsa: the sign method on ecdsa.PrivateKey does not hash #13938 (closed)
• proposal: crypto/x509: add VerifyOptions.UnknownAlgorithmVerifier #74024

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[x0wllaar]

You can verify a signature that was generated with external mu, you do not need to change anything in the verification. You just need to compute the mu as described here: https://www.rfc-editor.org/rfc/rfc9881.html#externalmu

See here for an example THAT YOU SHOULD NEVER USE IN PROD, but it still shows that the signature verifies correctly: https://go.dev/play/p/uvd0nSlnNk2?v=gotip

Verifying external mu via mu alone is not supported and you should not do that.

[gojuukaze]

You can verify a signature that was generated with external mu, you do not need to change anything in the verification. You just need to compute the mu as described here: https://www.rfc-editor.org/rfc/rfc9881.html#externalmu

See here for an example THAT YOU SHOULD NEVER USE IN PROD, but it still shows that the signature verifies correctly: https://go.dev/play/p/uvd0nSlnNk2?v=gotip

Verifying external mu via mu alone is not supported and you should not do that.

Thanks for the clarification. Our use case is slightly different.

We are implementing a hybrid P-256/ML-DSA signature scheme as a replacement for P-256. In our scheme, the computation of tr is modified to bind both public keys:

tr = Hash(p256_pk || ml_dsa_pk)

Consequently, mu is derived from this non-standard tr, rather than from the ML-DSA public key alone. The existing Verify API cannot reproduce this mu, so it cannot verify these signatures through its standard message-verification path.

We therefore need an API such as VerifyExternalMu to verify a caller-computed mu. Would exposing such an API be appropriate?

[x0wllaar]

Not advice you should take without independent review, but: I'd just prepend Hash(p256_pk || ml_dsa_pk) to the message and sign with the standard API rather than redefining tr.

IMO weird surgeries like that rarely end up well