On Wed, 12 Mar 2025 12:18:22 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> Implement HPKE as defined in https://datatracker.ietf.org/doc/rfc9180/. >>  > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > switch to Asserts.assertThrows in test; use traditional javadoc style 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 or crypto algorithm. There may also be some overlap with Red Hat's proposed Security Providers Filter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r1994216167
