JEP draft: Key Encapsulation Mechanism API

[Xuelei Fan]

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 exactly the same, like?

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

vs:

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

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
>>> 
>> 
>