bcprov 1.57: JCA SM3withSM2 signatures appear to hash the message twice. Intended?

[Juwan-Hwang]

Hello,

This is a question about historical behaviour, not a vulnerability report. Current releases behave as I would expect.

What we observe: in one JVM, with the GB/T 32918.5-2016 worked-example key pair and the same message:
• A signature from bcprov-jdk15on 1.57 via Signature.getInstance("SM3withSM2") verifies only under 1.57's own JCA path. It does not verify under 1.66 or 1.78, or under any standard SM2 implementation we tried, whether with the empty ID, the default ID "1234567812345678" or the real ID.
• The low-level SM2Signer in the same 1.57 jar produces a standard SM2 signature that verifies with the empty ID. It does not verify against 1.57's JCA path, and the JCA path's signatures do not verify against it.

How we read the 1.57 source: DSABase.engineSign() passes digest.doFinal() = SM3(M) to SM2Signer.generateSignature(byte[]). That method then computes SM3(Z_A || message), so e = SM3(Z_A || SM3(M)) and the message is hashed twice. From 1.66, GMSignatureSpi streams the message into a Signer-style SM2Signer, giving e = SM3(Z_A || M), and the default ID changes from empty to "1234567812345678". We read this as a consequence of the DSA to Signer API change, and we are not claiming BC knowingly fixed a defect.

Questions:

1. Was passing the digest into SM2Signer.generateSignature in 1.57 an intended digest-then-sign design, or a wiring mistake?
2. Did the algorithm name SM3withSM2 promise standard SM2 signatures in 1.57?
3. Which release between 1.58 and 1.65 changed this, and is there a commit or release note?
4. Are 1.57 JCA signatures expected not to verify under any standard implementation?

Environment: openjdk 17.0.20 (Temurin). Each probe ran on an isolated classpath with a single jar.
bcprov-jdk15on-1.57.jar sha256=4c7fb5f7fb043fedc4b7e7af88871050f61af8dea7aaade87f8ebd60e509cd89
bcprov-jdk15on-1.66.jar sha256=1b861dba1c5445de9b38a1789c211ef28b9d07e26d1fa38bee717e5b51162ffe
bcprov-jdk18on-1.78.jar sha256=1bf721b09758b3f55f2a5c875b6178ec6c41dddad854b0dead4b27a236f1943a
The reference implementation was calibrated against SM3("abc") from GB/T 32905-2016 Appendix A, and against Z_A for ID "1234567812345678" (B2E14C5C...CDA8A4F3) from the GB/T 32918.5 worked example.

What we are not claiming: no downstream impact was measured, no forgery or key recovery is involved, and the only observed effect is a verification failure. We have not tested SHA256withSM2 or bcprov-jdk15to18, and we have only narrowed the change to (1.57, 1.66].

Thanks for any insight.

[nicholas-greenwood]

1.59 is the release you're looking for. 1.58 still has the extra provider prehash; 1.59 streams the message directly to SM2Signer

there's a historical report for exactly what you found. #218 calls out both repeated sm3 hashing and the missing default id, with bcgit acknowledging the mistake. commit b071aa17 addresses both. the 1.59 release note explicitly records the default-id fix

for your last question, the 1.57 source amounts to signing SM3(M) as the message with an empty id. i'd try verifying those prehashed bytes, using the same public key and empty id. verification against M checks a different input, so those failures don't establish that no standard implementation could verify the signature

[Juwan-Hwang]

Thanks, Nicholas. That's very helpful, and you're right on all three points. I ran the test you suggested: for bcprov 1.57 and 1.58, 32 JCA SM3withSM2 signatures each verify 32/32 as (SM3(M), ID = "") under two independent SM2 verifiers (our GB/T 32918 reference and the 1.59 SM2Signer with explicit ParametersWithID), and 0/32 under every other combination; 1.59 signatures verify 32/32 only as (M, "1234567812345678"). So the mechanism is exactly sign(SM3(M), ID = ""). My earlier wording was wrong because I had only verified against M. Our write-up now credits #218 and b071aa1 as the original report and fix. Thanks for the quick and precise answer. Nothing further is needed from your side.