Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements
On 11/6/2019 11:27 AM, Sean Mullan wrote: Please remove this change to remove the Java SE requirements to implement security algorithms based on DES, MD5, or ECB. It makes sense to periodically review these requirements and remove algorithms or modes that are known to be weak and of which usage has declined significantly and thus compatibility risk is much lower. Note that we are not removing the actual implementations of these algorithms from the JDK. This just means that an SE implementation is not required to support these algorithms. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8233607 Thanks, Sean I don't have a problem with removing DES or MD5 from the must-implement list, but ECB is a fundamental building block mode. It's going to be how you implement a new mode before there's specific support for that mode. Pretty much any mode can be implemented using ECB as its only real crypto operation. E.g. CBC, CTR, CCM, GCM, CFB, OFB etc are all wrapped around ECB in some form. Please continue to require that it be implemented. Policy MAY restrict the use of the mode for a given key, but that's a provider issue. Mike
Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements
Hi Bernd, On 11/6/19 3:05 PM, Bernd Eckenfels wrote: Hello, While it is probably a good thing to not use ECB I can imagine you actually need it to implement single-block operations, so I am not sure if it’s a good idea if any general purpose JVM does not provide AES/ECB or RSA/ECB? (Maybe a new raw single block mode instead?) Hmm, that is a good point, so let me think a bit more about that. AES/ECB is also used in the SecureRandom CTR_DRBG mechanism implementation. For example TLS1.2 handshakes would need RSA/ECB/NoPadding and AES Key Exchange in smime would need AES/ECB as the primitive. Do you mean for wrapping the RSA premaster secret? Also, did you mean RSA/ECB/PKCS1Padding? RSA/ECB/NoPadding was not a requirement. On the other hand, requiring 3DES might really not be a requirement anymore, while at it remove it, also? I did think about that, but industry-wide deprecation of 3DES is more recent than DES. I would like to hold off on that for now until we understand the compatibility risk a little better for certain components such as Kerberos. --Sean Gruss Bernd -- http://bernd.eckenfels.net *Von:* security-dev im Auftrag von Sean Mullan *Gesendet:* Mittwoch, November 6, 2019 5:28 PM *An:* security Dev OpenJDK *Betreff:* RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements Please remove this change to remove the Java SE requirements to implement security algorithms based on DES, MD5, or ECB. It makes sense to periodically review these requirements and remove algorithms or modes that are known to be weak and of which usage has declined significantly and thus compatibility risk is much lower. Note that we are not removing the actual implementations of these algorithms from the JDK. This just means that an SE implementation is not required to support these algorithms. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8233607 Thanks, Sean
Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements
Hello, While it is probably a good thing to not use ECB I can imagine you actually need it to implement single-block operations, so I am not sure if it’s a good idea if any general purpose JVM does not provide AES/ECB or RSA/ECB? (Maybe a new raw single block mode instead?) For example TLS1.2 handshakes would need RSA/ECB/NoPadding and AES Key Exchange in smime would need AES/ECB as the primitive. On the other hand, requiring 3DES might really not be a requirement anymore, while at it remove it, also? Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev im Auftrag von Sean Mullan Gesendet: Mittwoch, November 6, 2019 5:28 PM An: security Dev OpenJDK Betreff: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements Please remove this change to remove the Java SE requirements to implement security algorithms based on DES, MD5, or ECB. It makes sense to periodically review these requirements and remove algorithms or modes that are known to be weak and of which usage has declined significantly and thus compatibility risk is much lower. Note that we are not removing the actual implementations of these algorithms from the JDK. This just means that an SE implementation is not required to support these algorithms. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8233607 Thanks, Sean
Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements
On 11/6/19 11:40 AM, Xuelei Fan wrote: Looks good to me. Thanks. Also, someone spotted a typo in my message below: Xuelei On 11/6/2019 8:27 AM, Sean Mullan wrote: Please remove this change to remove the Java SE requirements to Should be "Please review ..." --Sean implement security algorithms based on DES, MD5, or ECB. It makes sense to periodically review these requirements and remove algorithms or modes that are known to be weak and of which usage has declined significantly and thus compatibility risk is much lower. Note that we are not removing the actual implementations of these algorithms from the JDK. This just means that an SE implementation is not required to support these algorithms. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8233607 Thanks, Sean
Re: RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements
Looks good to me. Xuelei On 11/6/2019 8:27 AM, Sean Mullan wrote: Please remove this change to remove the Java SE requirements to implement security algorithms based on DES, MD5, or ECB. It makes sense to periodically review these requirements and remove algorithms or modes that are known to be weak and of which usage has declined significantly and thus compatibility risk is much lower. Note that we are not removing the actual implementations of these algorithms from the JDK. This just means that an SE implementation is not required to support these algorithms. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8233607 Thanks, Sean
RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements
Please remove this change to remove the Java SE requirements to implement security algorithms based on DES, MD5, or ECB. It makes sense to periodically review these requirements and remove algorithms or modes that are known to be weak and of which usage has declined significantly and thus compatibility risk is much lower. Note that we are not removing the actual implementations of these algorithms from the JDK. This just means that an SE implementation is not required to support these algorithms. webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8233607 Thanks, Sean
Re: RFR [14] 8223940: Private key not supported by chosen signature algorithm
On 11/5/2019 4:49 PM, Valerie Peng wrote: Hi Xuelei, Updated webrev looks good. If we have a failing test to verify the changes, perhaps you can try disabling the CKM_RSA_PKCS_PSS in the PKCS11 provider configuration file. Or, you can always comment out the PSS Signature entry registration in SunPKCS11 provider. Yes, I commented out the PSS signature items in SunPKCS11 provider, and the JPRT result looks good. Thanks, Xuelei Thanks, Valerie On 11/4/2019 7:27 PM, Xuelei Fan wrote: Hi Valerie, Thanks for the review. On 11/4/2019 6:36 PM, Valerie Peng wrote: Hi Xuelei, Overall changes look good. A nit: SignatureScheme.java:552, "Ignore unsupport..." instead of "Ignore the unsupported..." Good catch! It seems that the SignatureScheme selection is always selected with PrivateKey first? Yes. It'd be nice to have some comments explain the different handling between getSigner(PrivateKey) and getVerifier(PublicKey), i.e. former returns null vs later passes up the exception. Yes, better to have some words for the difference. Here is the updated webrev: http://cr.openjdk.java.net/~xuelei/8223940/webrev.01/ Comparing to the previous version, only the SignatureScheme.java is updated. Thanks, Xuelei Thanks, Valerie On 10/24/2019 1:56 PM, Xuelei Fan wrote: Hi, Could I get the following update reviewed? http://cr.openjdk.java.net/~xuelei/8223940/webrev.00/ For signature algorithms, the update will fail back to use the supported signature algorithm for the specific private key. Previously, the first preferred signature algorithm get used ad the private key may not be able to work with the signature algorithm however. No new regression test as RSASSA-PSS has been supported in the SunPKCS11 provider currently. Can I get a help for the test if you are running a provider that does not support RSASSA-PSS yet? Thanks & Regards, Xuelei
