-
Sub-task
-
Resolution: Delivered
-
P4
-
None
-
6u171, 7u161, 8u151
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8186041 | 8u151 | Clifford Wayne | P4 | Closed | Delivered | |
JDK-8186040 | 7u161 | Clifford Wayne | P4 | Closed | Delivered | |
JDK-8186039 | 6u171 | Clifford Wayne | P4 | Closed | Delivered |
For DSA keys, the default signature algorithm for `keytool` and `jarsigner` has changed from SHA1withDSA to SHA256withDSA and the default key size for `keytool` has changed from 1024 bits to 2048 bits.
Users wishing to revert to the previous behavior can use the `-sigalg` option of `keytool` and `jarsigner` and specify SHA1withDSA and the `-keysize` option of `keytool` and specify 1024.
There are a few potential compatibility risks associated with this change:
1. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:
```
keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...
```
it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:
```
keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits
```
The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to specify a smaller key size (1024).
2. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on an earlier release of JDK 6 or 7 will output the following error:
```
jar is unsigned. (signatures missing or not parsable)
```
If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output:
```
jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available
```
If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm.
3. If you use a `PKCS11` keystore, the SunPKCS11 provider does not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex:
```
keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey
```
A similar error may occur if you are using NSS with the SunPKCS11 provider.
The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA.
Users wishing to revert to the previous behavior can use the `-sigalg` option of `keytool` and `jarsigner` and specify SHA1withDSA and the `-keysize` option of `keytool` and specify 1024.
There are a few potential compatibility risks associated with this change:
1. If you have a script that uses the default key size of `keytool` to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:
```
keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...
```
it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:
```
keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits
```
The workaround is to remove the `-sigalg` option and use the stronger SHA256withDSA default or, at your own risk, use the `-keysize` option of `keytool` to specify a smaller key size (1024).
2. If you use `jarsigner` to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. `jarsigner -verify` on an earlier release of JDK 6 or 7 will output the following error:
```
jar is unsigned. (signatures missing or not parsable)
```
If you add `-J-Djava.security.debug=jar` to the `jarsigner` command line, the cause will be output:
```
jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available
```
If compatibility with earlier releases is important, you can, at your own risk, use the `-sigalg` option of `jarsigner` and specify the weaker SHA1withDSA algorithm.
3. If you use a `PKCS11` keystore, the SunPKCS11 provider does not support the `SHA256withDSA` algorithm. `jarsigner` and some `keytool` commands may fail with the following exception if `PKCS11` is specified with the `-storetype` option, ex:
```
keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey
```
A similar error may occur if you are using NSS with the SunPKCS11 provider.
The workaround is to use the `-sigalg` option of `keytool` and specify SHA1withDSA.
- backported by
-
JDK-8186039 Release Note: New defaults for DSA keys in jarsigner and keytool
- Closed
-
JDK-8186040 Release Note: New defaults for DSA keys in jarsigner and keytool
- Closed
-
JDK-8186041 Release Note: New defaults for DSA keys in jarsigner and keytool
- Closed