RFR: 8346129: Simplify EdDSA & XDH curve name usage
Weijun Wang
weijun at openjdk.org
Fri Feb 21 22:07:52 UTC 2025
On Fri, 21 Feb 2025 21:09:32 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:
>> src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 95:
>>
>>> 93: case "Ed25519" -> {
>>> 94: if (aliasEd25519 == null) {
>>> 95: aliasEd25519 = List.of("EdDSA", "Ed25519");
>>
>> Hmm. Should disabling Ed25519 also disable EdDSA? I can see the reverse, but isn't Ed25519 meant to be a specific curve for EdDSA?
>
> This is complicated by `KeyPairGenerator.getInstance("EdDSA")` returning an Ed25519 key
>
> If someone were to check permits() with "EdDSA" the above code recognizes that "Ed25519" on the disabled algorithm list overlaps with "EdDSA". This is the first test in the test coded included in the PR.
Do we call `permits` before instantiating a `KeyPairGenerator`? What if people call `kpg.initialize(NPS.Ed448)` after the instantiation?
In reality, I think it depends on how many `permits` calls there are. Modern algorithms have the key same algorithm name and signature algorithm name. When a signature operation is carried out, do we check on both the signature algorithm and the key? It seems only checking on the key is enough. It's actually more precise, since you can get the exact parameter set name there. This is why I asked if the method is "never called on a family algorithm name". When checking a key, if we always call `permits` on the parameter set name, we get the precise result.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23647#discussion_r1966259933
More information about the security-dev
mailing list