On Tue, 7 Jan 2025 14:58:22 GMT, Weijun Wang <[email protected]> wrote:
>> Allow `Generic` as an algorithm in the `KeyAgreement::generateSecret(alg)`
>> method.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> cleaner test and harden p11-nss-sensitive.txt
src/java.base/share/classes/javax/crypto/KeyAgreement.java line 668:
> 666: * Java Security Standard Algorithm Names Specification</a>
> 667: * for information about standard secret key algorithm names.
> 668: * Use "Generic" if the output will be used as the input keying
s/Use/Specify/
src/java.base/share/classes/javax/crypto/KeyAgreement.java line 674:
> 672: * may be adjusted to be compatible with the specified
> algorithm,
> 673: * regardless of whether the key is extractable. If {@code
> algorithm}
> 674: * is specified as "Generic", the full shared secret will be
> returned.
I think this last sentence is too strict, as some existing provider
implementations may not support "Generic". I would suggest rewording as "If
{@code algorithm} is specified as "Generic" and is supported by the
implementation, the full shared secret is returned."
src/java.base/share/classes/sun/security/ec/ECDHKeyAgreement.java line 260:
> 258: if (!KeyUtil.isSupportedKeyAgreementOutputAlgorithm(algorithm)) {
> 259: throw new NoSuchAlgorithmException
> 260: ("Only supported for algorithm TlsPremasterSecret");
Should the exception message and algorithm param in line 262 be less specific
and use the algorithm parameter? i.e.:
`("Not supported for algorithm " + algorithm);`
and:
`SecretKeySpec(engineGenerateSecret(), algorithm)`
Same comment for a few other files.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22650#discussion_r1905862697
PR Review Comment: https://git.openjdk.org/jdk/pull/22650#discussion_r1905869075
PR Review Comment: https://git.openjdk.org/jdk/pull/22650#discussion_r1905837938
