> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote:
> If someone really cares about the result of getProvider(), they should be
> careful no other thread calls encapsulation or decapsulation.
If no-one care about the result of getProvider(), is it possible to remove this
method from the desi
On Fri, 20 Jan 2023 22:03:29 GMT, Hai-May Chao wrote:
>> Please review the fix to address the problem in keytool -genseckey and
>> -importpass.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update with Max's comment
Yes
> On Jan 25, 2023, at 11:13 PM, Xuelei Fan wrote:
>
> For delayed provider selection, what’s the selection behavior for
> KEM.getProvider()and KEM.getInstance(String alg, Provider p)?
If getInstance(alg, p) is called, there won't be delayed provider selection.
> Could the provider be determi
For delayed provider selection, what’s the selection behavior for
KEM.getProvider()and KEM.getInstance(String alg, Provider p)? Could the
provider be determined and reliable if the methods are used in an application?
Is the behavior the same if the calling sequences in an application are not
e
> This RFE enhances existing PBE algorithms with the "SHA512/224" and
> "SHA512/256" support.
> Current transformation parsing in javax.crypto.Cipher class is re-written to
> handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm
> names. Existing tests are updated with the ad
Hi -
I need to repeat again. Please avoid using www.ietf.org as the URL base
for referencing RFCs. The appropriate location is www.rfc-editor.org
and is going to be more stable in the long run than any reference to an
RFC that runs through the IETF's website. These two websites have
differ
Hi Xuelei,
That's a bold suggestion. However, we'd like to the tradition of JCA/JCE at the
moment.
Thanks,
Max
> On Jan 25, 2023, at 3:03 PM, Xuelei Fan wrote:
>
> For new set of service APIs, it may be worthy of considering to simplify the
> design and avoid duplicated SPIs by using java.
For new set of service APIs, it may be worthy of considering to simplify the
design and avoid duplicated SPIs by using java.util.ServiceLoade.
Xuelei
> On Jan 25, 2023, at 11:24 AM, Wei-Jun Wang wrote:
>
> Hi All,
>
> We are working on providing a new API for KEM (Key Encapsulation Mechanism)
Hi All,
We are working on providing a new API for KEM (Key Encapsulation Mechanism).
There will be a KEM class for users along with a KEMSpi class for security
providers, and several other parameter and exception classes.
You can read the draft JEP at https://openjdk.org/jeps/8301034.
Feel fre
Hi,
Can I get help filing a JBS issue for the following PR which
resurrects the VerifySignedJar test now that SHA-1 is disabled:
https://github.com/openjdk/jdk/pull/12206
Thanks,
Eirik.
On Wed, 25 Jan 2023 16:12:12 GMT, Matthew Donovan wrote:
>> Eirik Bjorsnos has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add whitespace between if and left parenthesis
>
> test/jdk/jdk/security/jarsigner/JarWithOneNonDisabledDigestAlg.
On Tue, 24 Jan 2023 12:18:10 GMT, Eirik Bjorsnos wrote:
>> This PR attempts to make JarWithOneNonDisabledDigestAlg a little easier to
>> read.
>>
>> Some changes are made in the choice of algorithms and naming. The intent
>> here is to reduce confusion and make the purpose of the test clearer
On Fri, 20 Jan 2023 22:03:29 GMT, Hai-May Chao wrote:
>> Please review the fix to address the problem in keytool -genseckey and
>> -importpass.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update with Max's comment
I t
On Fri, 20 Jan 2023 22:03:29 GMT, Hai-May Chao wrote:
>> Please review the fix to address the problem in keytool -genseckey and
>> -importpass.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update with Max's comment
Mar
14 matches
Mail list logo
