RFR: 8325448: Hybrid Public Key Encryption [v10]
Weijun Wang
weijun at openjdk.org
Fri Mar 14 14:09:50 UTC 2025
On Thu, 13 Mar 2025 20:15:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>> src/java.base/share/conf/security/java.security line 671:
>>
>>> 669: # jdk.hpke.disabledAlgorithms=kem_id=0x10,kdf_id=0x01,aead_id=0xffff
>>> 670: #
>>> 671: jdk.hpke.disabledAlgorithms=
>>
>> Do you expect that these algorithm ids would be embedded in some higher level network protocols or artifacts and thus could potentially be leveraged that way? Trying to understand the motivation/need for this property, as we have not (as of yet) disabled algorithms at the JCE layer, with the rationale that it is up to the developer to understand the security risks of directly using a weak crypto algorithm.
>>
>> There may also be some overlap with Red Hat's proposed Security Providers Filter.
>
> You’re right. I can remove this part if there’s no requirement yet. For TLS, we already enforce constraints through the existing TLS security property. Perhaps another usage scope is enough when we start supporting Encrypted ClientHello.
Removed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1995642460
More information about the security-dev
mailing list