RFR: 8286907: keytool should warn about weak PBE algorithms [v2]

[Hai-May Chao]

On Thu, 26 Jan 2023 12:30:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with Max's comment
>
> I said "one solution is to add RC2_40 and RC2_128" but now I'm not sure if it's the right solution. We can always resolve this in a separate issue, but I think we'd better have an agreement on whether the current decomposer implementation is correct about "RC2" not covering "RC2_40". If yes and one day we decide to disable AES, then we should disable all of AES_128, AES_192 and AES_256 since there are algorithm names like AES_192/OFB/NoPadding and PBEWithHmacSHA384AndAES_128. This does not sound very right to me.
> 
> Valerie is adding PBES2Core$HmacSHA512_224AndAES_256 in another PR now. In that case, SHA512 should not cover HmacSHA512_224 (although we are not likely to disable HmacSHA512 before disabling HmacSHA512_224 first). So this is a little complicated.

@wangweij @seanjmullan For the scenario, i.e. PBEWithSHA1AndRC2_40 after SHA1 removal, we probably could
treat RC2_40 as RC2 after decomposing. For another scenario, adding RC2 KeySize < 40, we currently have a similar test case (i.e. AES keySize < 256) in WeakSecretKeyTest.java, and keytool will emit warning as a result of keysize constraint checking. The question arises is does it apply to PBEWithSHA1AndRC2_40 as well? I’d think it should if we treat RC2_40 as RC2 after decomposing. However, the PBEKey generated for PBEWithSHA1AndRC2_40 will have PBEwithMD5andDES algorithm. Algorithm constraint checking on MD5 would take place earlier than keysize constraint checking. As a result, warnings for keysize constraint will not be emitted. These are my current thoughts and more thoughts surely are needed to address JDK-8301127.
I suggest we look at the possible issues with various corner cases in algorithm decomposing and keysize constraints, etc, for PBExxx and Hmacxxx in JDK-8301127. Do you agree JDK-8301127 would serve the need?

-------------

PR: https://git.openjdk.org/jdk/pull/12056