Update to JEP draft: Key Encapsulation Mechanism API

[Xuelei Fan]

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("DHKEM”);
2. var pkR = retrieveKey();
3. var e = kemS.newEncapsulater(pkR);
4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
5. var secS = enc.key();
6. sendBytes(enc.encapsulation());


At 2023, a new DerivedKeyParameterSpec algorithm or spec could be defined.  For example, the new algorithm is “ZES”.  An application may use “ZES" as:

1. var kemS = KEM.getInstance("DHKEM”);
2. var pkR = retrieveKey();
3. var e = kemS.newEncapsulater(pkR);
- 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));
+ 4. var enc = e.encapsulate(new DerivedKeyParameterSpec(“ZES", 32));
5. var secS = enc.key();
6. sendBytes(enc.encapsulation());


The provider A implemented before 2023 cannot support AES, and another provider B updated after 2023 could.  Suppose there are two providers, and provider A is preferred, will the application that use “ZES” work as expected (choose provider B)?  Per the current JEP, It looks like provider A will be selected at line 3, and exception could be thrown at line 4.

Thanks,
Xuelei

> On Feb 3, 2023, at 2:53 PM, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi All,
> 
> Thanks for all the feedbacks. One of them [1] from Bernd Eckenfels is about Hybrid TLS Key Exchange. I read the IETF draft on it [2] and noticed something that the current KEM API cannot handle. It says the 2 ciphertext for each sub-KEM will be concatenated into a longer byte array as the ciphertext of the hybrid KEM. This brings up a problem on the decapsulator side: how can we split the long array into two if we don't know the size of each sub-ciphertext?
> 
> David Hook mentioned that RSA-KEM has a similar problem.
> 
> Therefore we decide to add a getCiphertextSize() method, and it can only be called after the private key is known. The decapsulation will be broken into multiple steps: the key is provided first, you have a chance to get the ciphertext size, and then perform the actual decapsulation. But instead of choosing Signature's initSign-then-sign approach which is on the same object and thus not thread-safe and mutable, the 1st step will return a Decapsulator object and this Decapsulator is used to perform the other steps, including the new size retrieval methods and the actual decapsulation function. The same is done on the encapsulation side.
> 
> We also take this chance to rename "ciphertext" into "key encapsulation message". This is the name used in the PQC APIs [4] and this avoids confusing with encryption output of a Cipher. This is also a suggestion from David Hook.
> 
> Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.
> 
> Thanks,
> Max
> 
> [1] https://mastodon.social/@eckes@zusammenkunft.net/109752008992193461
> [2] https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html#name-transmitting-public-keys-an <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>
> [3] https://www.rfc-editor.org/rfc/rfc5990#appendix-A.2
> [4] https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf
> 
> 
>> On Jan 25, 2023, at 2:24 PM, 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
>> 
>