On Thu, 5 Nov 2026 13:00:00 GMT, Weijun Wang <[email protected]> wrote:
>> I think we can not skip the `KeyPairGenerator` and KEM probes as >> `NamedGroup.isAvailable()` decides whether a group is enabled, advertised, >> and selected during TLS 1.3 keyshare negotiation. Without those checks, a >> hybrid group could be advertised even when no provider can create its key >> pair or perform its KEM operation. > > I considered whether we could simply call `GetInstance.getService()`, since > instantiating a hybrid `KeyPairGenerator` or `KEM` is quite expensive, as it > also instantiates the sub KPGs or KEMs. However, without instantiating them, > I don't know if there is a reliable way to find out whether the components > are available. If we introduce features that disable or filter algorithms in > the future, it will likely become even more difficult to confirm it. If we only call `GetInstance.getService()` for `KEM`, it finds the first registered matching Provider.Service. But it will not check whether that provider can be used by JCE. It does not apply all JCE usable providers. It does not consider later matching providers, and will not create delayed selection KEM object. `KEM.getInstance(algorithm)` does not instantiate a KEMSpi and is less expensive than `KeyPairGenerator`. If we only call GetInstance.getService() for `KeyPairGenerator`, it returns the first registered matching provider service without instantiating it. It will not fall back to next provider as it can not detect if there may be a constructor failure. The `NamedGroup.isAvailable()` could report the group as available even the selected KPG can not be created and would cause TLS keyshare generation to fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/33433#discussion_r4486548899
