JEP draft: Key Encapsulation Mechanism API

[Wei-Jun Wang]

> On Jan 25, 2023, at 11:13 PM, Xuelei Fan <xuelei.f at gmail.com> 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 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 exactly the same, like?
> 
>    kem = …
>    var provider = kem.getProvider();
>    // use the provider information
>    kem.encapsulate(…);

If getProvider() is called before encapsulation. Most likely it will be the 1st provider that supports this algorithm. This is not specified but we know there is an order for the providers.

> 
> vs:
> 
>    kem = …
>    kem.encapsulate(…);
>    var provider = kem.getProvider();
>    // use the provider information

This provider will be the implementation that actually performed the encapsulation function.

The delayed provider selection in existing crypto primitives like Signature and KeyAgreement only allows the selection once. If it's determined then it will not change. When designing KEM, we think this is unnecessary. Of course this makes the class more mutable. If someone really cares about the result of getProvider(), they should be careful no other thread calls encapsulation or decapsulation.

Thanks,
Max

> 
> Xuelei
> 
> 
> 
>> On Jan 25, 2023, at 1:03 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> 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 <xuelei.f at gmail.com> wrote:
>>> 
>>> 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 <weijun.wang at oracle.com> wrote:
>>>> 
>>>> 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 free to add any comment here.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
>>> 
>> 
>