JDK-8196952 : Bad primeCertainty value setting in DSAParameterGenerator
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 8u161
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-02-07
  • Updated: 2019-01-14
  • Resolved: 2018-02-23
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 8 Other
8u171Fixed openjdk7uFixed
Related Reports
Relates :  
JDK-8072452 - Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits
Description
The recent JDK-8072452 fix places a bad initial value of 80 on the primeCertainty variable and negates a value check done later in the same code : 

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/annotate/6920e7e273e6/src/share/classes/sun/security/provider/DSAParameterGenerator.java#l208

we should set the value to -1 as per another recent fix done in this area via JDK-8181048 

JDK 10 code looks ok.
Comments
Requesting backport to 8u171 as this regression should really be cleaned up sooner rather than later.
23-02-2018
Review thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-February/007255.html
23-02-2018
It's an issue only relevant to OpenJDK 8 and any further backports that use the version from that repository. In OpenJDK 9 and up, the work in 8072452 was done in April 2016, and 8181048 in July 2017. 8072452 was not backported to OpenJDK 8 until this update (October 2017), so the two changes were applied there in the opposite order. The main issue is that 8181048 has this change: - int primeCertainty = 80; // for 1024-bit prime P - if (valueL == 2048) { + int primeCertainty = -1; + if (valueL <= 1024) { + primeCertainty = 80; + } else if (valueL == 2048) { But then the backport of 8072452 reverts part of it: @@ -205,11 +206,13 @@ int b = (valueL - 1) % outLen; byte[] seedBytes = new byte[seedLen/8]; BigInteger twoSl = TWO.pow(seedLen); - int primeCertainty = -1; + int primeCertainty = 80; // for 1024-bit prime P if (valueL <= 1024) { primeCertainty = 80; } else if (valueL == 2048) { primeCertainty = 112; + } else if (valueL == 3072) { + primeCertainty = 128; } if (primeCertainty < 0) { So primeCertainty is never going to be < 0. I caught this because I backported 8072452 in IcedTea last May, and so the changes happened in the same order as in 9, then the merge with 8u161 threw up these issues. There are some other minor differences but that's the main one that may potentially affect behaviour. I'll attach the full patch I have.
08-02-2018
Thanks to Andrew Hughes for spotting the issue.
08-02-2018