On Fri, 3 Jan 2025 20:54:06 GMT, Sean Mullan wrote:
>> Do you suggest me adding the same to `encapsulate` and `decapsulate` of
>> `KEM` in this PR? I can update the title to include it.
>
> Yes.
Finally, no. KEM changes will be in https://github.com/openjdk/jdk/pull/22929.
-
PR Re
On Fri, 3 Jan 2025 16:55:09 GMT, Weijun Wang wrote:
>> Good idea.
>
> Do you suggest me adding the same to `encapsulate` and `decapsulate` of `KEM`
> in this PR? I can update the title to include it.
Yes.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/22650#discussion_r1902
On Fri, 3 Jan 2025 16:17:43 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/javax/crypto/KeyAgreement.java line 662:
>>
>>> 660: * subsequent operations.
>>> 661: *
>>> 662: * @param algorithm the requested secret-key algorithm. This is
>>
>> Did you consider instead refer
On Fri, 3 Jan 2025 13:41:05 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add key size adjustment clarification
>
> src/java.base/share/classes/javax/crypto/KeyAgreement.java line 662:
>
>> 660:
On Wed, 18 Dec 2024 22:33:28 GMT, Weijun Wang 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:
>
> add key size adjustment clarifica
I ran into a few problems related to a similar approach in my own code.
Basically, PKCS12 requires some sort of OID/Algorithm identifier to map
to/from the algorithm name. Anything that you allow for here ideally
needs to be supported by KeyStore there. It doesn't help that PKCS11 has
CKK_G
> 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:
add key size adjustment clarification
-
Changes:
- all: https://git.openjdk.org/jdk
