>
> Given that removing these APIs would cause TCK issues in these cases, I
> have been reticent to remove the APIs. At this point, I view this to be
> in a holding pattern until we have a very strong confidence that it
> won't break EE implementations.
>
I have been exploring the effects of remov
On Tue, 21 Mar 2023 20:31:44 GMT, Martin Balao wrote:
>> We would like to propose an implementation for the [JDK-8301553: Support
>> Password-Based Cryptography in
>> SunPKCS11](https://bugs.openjdk.org/browse/JDK-8301553) enhancement
>> requirement.
>>
>> In addition to pursuing the requirem
> The KEM API and DHKEM impl. Note that this PR uses new methods in
> https://github.com/openjdk/jdk/pull/13250.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
fine tuning spec
-
Changes:
- all: https://git.openjdk.or
On Fri, 14 Apr 2023 00:42:52 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/javax/crypto/KEM.java line 246:
>>
>>> 244:
>>> 245: /**
>>> 246: * The key encapsulation function.
>>
>> I think it would be useful to add a sentence explaining when this method
>> would be u
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/java.smartcardio/unix/native/libj
On Tue, 18 Apr 2023 16:32:49 GMT, Weijun Wang wrote:
>> The KEM API and DHKEM impl. Note that this PR uses new methods in
>> https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fine tu
> The KEM API and DHKEM impl. Note that this PR uses new methods in
> https://github.com/openjdk/jdk/pull/13250.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
move Encapsulator before Decapsulator
-
Changes:
- all: h
> The KEM API and DHKEM impl. Note that this PR uses new methods in
> https://github.com/openjdk/jdk/pull/13250.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
fine tune spec
-
Changes:
- all: https://git.openjdk.org/
On Fri, 14 Apr 2023 14:21:05 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/javax/crypto/KEM.java line 242:
>>
>>> 240: * shared secret as a key with algorithm being
>>> "Generic",
>>> 241: * the key encapsulation message, and optional
>>> parameters
On Fri, 14 Apr 2023 01:59:59 GMT, Xue-Lei Andrew Fan wrote:
>> I can rewrite this into something like "The caller of this method must
>> validate..." so it becomes a requirement. We'll make sure the `KEM` class
>> follows it. Any other class that wishes to call it directly must do it as
>> wel
On Fri, 14 Apr 2023 14:33:56 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/javax/crypto/KEM.java line 94:
>>
>>> 92: * @see KEM#newEncapsulator(PublicKey, AlgorithmParameterSpec,
>>> SecureRandom)
>>> 93: */
>>> 94: public record Encapsulated(SecretKey key, byte[] encapsu
On Fri, 14 Apr 2023 16:54:49 GMT, Weijun Wang wrote:
>> The KEM API and DHKEM impl. Note that this PR uses new methods in
>> https://github.com/openjdk/jdk/pull/13250.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> spec ch
> The KEM API and DHKEM impl. Note that this PR uses new methods in
> https://github.com/openjdk/jdk/pull/13250.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
let implementor validate arguments, null key throws IKE
-
C
>
> Given the compatibility risks/impacts with existing providers and JSSE
>> implementations, we've decided to withdraw this CSR for the time being.
>
>
One of the concerns raised by Alan in the CSR was related to SPECjbb2015:
The Grizzly framework is used in SPECjbb2015 for example, will it mean
14 matches
Mail list logo
