Hi All,
The JEP draft was just updated again.
The KEMParameterSpec argument is moved from getInstance() to newEncapsulator()
and newDecapsulator(). The reason is that when delayed provider selection
happens, a KEMSpi object is only created when newEncapsulator/newDecapsulator
is called. If the
Betreff: Re: Update to JEP draft: Key Encapsulation Mechanism API
> On Mar 3, 2023, at 12:37 PM, Bernd wrote:
>
> Will „Generic“ work with ciphers which need „raw“, or is that intentionally not the case?
Not sure if I understand. "Raw" is the format type.
"Generic"
dev On Behalf Of Wei-Jun Wang
> Sent: Friday, March 3, 2023 12:30 PM
> To: security-...@openjdk.java.net
> Subject: [EXTERNAL] Re: Update to JEP draft: Key Encapsulation Mechanism API
>
> WARNING: This email originated outside of Entrust.
> D
gt; An: security-...@openjdk.java.net
> Betreff: Re: Update to JEP draft: Key Encapsulation Mechanism API
> Hi All,
>
> The JEP draft was just updated again.
>
> The major change is that there is no more DerivedKeyParameterSpec class Maybe
> it's because of the na
: security-dev On Behalf Of Wei-Jun Wang
Sent: Friday, March 3, 2023 12:30 PM
To: security-...@openjdk.java.net
Subject: [EXTERNAL] Re: Update to JEP draft: Key Encapsulation Mechanism API
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender
-...@openjdk.java.net Betreff: Re: Update to JEP draft: Key Encapsulation Mechanism API Hi All,
The JEP draft was just updated again.
The major change is that there is no more DerivedKeyParameterSpec class Maybe it's because of the name, but we found many people treating it as a place to configur
Hi All,
The JEP draft was just updated again.
The major change is that there is no more DerivedKeyParameterSpec class. Maybe
it's because of the name, but we found many people treating it as a place to
configure the KDF used inside a KEM. Actually the only usage of it is to give
caller a chanc
var cek = KeyGenerator.getInstance("ZES").generateKey();
var ikm = KEM.getInstance("DHKEM”, pkR, new
DerivedKeyParameterSpec("HKDF")).encapsulate().key();
var kek = KDF.getInstance("HKDF", ikm, new DerivedKeyParameterSpec("YESWrap",
32)).extract();
var ek = Cipher.getInstance("YESWrap").init(WRA
On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang wrote:
> Hi Xuelei,
>
> This is a very interesting case since both crypto primitives (KEM and
> Cipher) require delayed provider selection.
>
> I would say line 4 should not throw an exception. A KEM should not reject
> any algorithm name, because it mi
Hi Xuelei,
This is a very interesting case since both crypto primitives (KEM and Cipher)
require delayed provider selection.
I would say line 4 should not throw an exception. A KEM should not reject any
algorithm name, because it might be any string. It's very likely that the
shared secret is
Hi,
Thank you for the update.
What’s the different impact of parameters like algorithm name,
KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I’m not
very sure of it.
For example, at 2013, the following cord should work without any issues:
1. var kemS = KEM.getInstance("
11 matches
Mail list logo
