JDK-8147502 : Digest is incorrectly truncated for ECDSA signatures when the bit length of n is less than the field size
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8,9,12,13
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-01-16
  • Updated: 2019-09-04
  • Resolved: 2019-03-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 13 JDK 7 JDK 8 Other
11.0.5-oracleFixed 12u-cpuFixed 13 b13Fixed 7u241Fixed 8u231Fixed openjdk8u232Fixed
Related Reports
Relates :  
The message digest is incorrectly truncated for ECDSA signatures when the bit length of the base point order, n, is not equal to the field size. 

In sun/security/ec/impl/ec.c ECDSA_SignDigestWithSeed() lines 755-760, the digest is truncated using the following code:
    /* In the definition of EC signing, digests are truncated
     * to the length of n in bits.
     * (see SEC 1 "Elliptic Curve Digit Signature Algorithm" section 4.1.*/
    if (digest->len*8 > (unsigned int)ecParams->fieldID.size) {
        mpl_rsh(&s,&s,digest->len*8 - ecParams->fieldID.size);

However, the fieldID.size is not necessarily equal to the number of bits in the base point order, n. For example, with the standard F2M curves sect163r1 and sect283r1, the number of bits in n is one less than the field size: 162 and 282 bits, respectively. This leads to incorrect signatures when using hash algorithms that produce message digests longer than the field size.

Some cases to reproduce the issue are:
sect163r1 for ECDSA signatures using SHA 256, 384, 512
sect283r1 for ECDSA signatures using SHA 384, 512

I observed this issue when using jdk1.7.0_45, and still see the above code in the source for openjdk-8-src-b132-03_mar_2014.zip. 

Fix Request (jdk8u): Requesting backport to jdk8u as this release is affected by this bug. Patch does not apply cleanly. Review requested in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009987.html

Fix Request: Requesting backport to 11u because it's part of Oracle 11.0.5. Patch applies cleanly net copyright years in src/jdk.crypto.ec/share/native/libsunec/impl/ec.c and fuzz in src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSASignature.java Backport will be tested in SAP's test system before pushing.

From a scan of the code, I agree that it should produce incorrect results for these combinations of curves and hash functions. Unfortunately, we don't have unit tests for all the supported curve/digest combinations. So I created JDK-8189189 to track the task of adding these tests. It's worth noting that the affected curves are not widely used, and many newer browsers and crypto libraries don't support them at all.