RFR: 8189441: Define algorithm names for keys derived from KeyAgreement [v11]
Sean Mullan
mullan at openjdk.org
Tue Jan 7 18:28:42 UTC 2025
On Tue, 7 Jan 2025 14:58:22 GMT, Weijun Wang <weijun at openjdk.org> 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
More information about the security-dev
mailing list