On Sat, 22 May 2021 01:02:50 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> Valerie Peng has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge master into JDK-8248268
>> - Minor update to address review comments.
>> - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>> KWParameters and KWPParameters.
>> - Refactor code to reduce code duplication
>> Address review comments
>> Add more test vectors
>> - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>> AES/KWP/NoPadding
>> - Restored Iv algorithm parameters impl.
>> - 8248268: Support KWP in addition to KW
>>
>> Updated existing AESWrap support with AES/KW/NoPadding cipher
>> transformation. Added support for AES/KWP/NoPadding and
>> AES/KW/PKCS5Padding support to SunJCE provider.
>
> src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line
> 176:
>
>> 174: return ConstructKeys.constructPublicKey(encoding,
>> keyAlgorithm);
>> 175: default:
>> 176: throw new RuntimeException("Unsupported key type");
>
> Good improvement to thrown an exception rather than return "null"!
>
> Is NoSuchAlgorithmException fitted better the specification? See also the
> comment in KeyWrapCipher.engineUnwrap().
Yes, will change.
> src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line
> 710:
>
>> 708: outLen = helperDecrypt(dataBuf, dataIdx);
>> 709: return ConstructKeys.constructKey(dataBuf, 0, outLen,
>> 710: wrappedKeyAlgorithm, wrappedKeyType);
>
> Per the specification of engineUnwrap, maybe, the
> ConstructKeys.constructKey() implementation could throw
> NoSuchAlgorithmException if wrappedKeyType is unknown. See the common in the
> the ConstructKeys.constructKey() implementation.
Sure, makes sense.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2404
