Update to JEP draft: Key Encapsulation Mechanism API

[Wei-Jun Wang]

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
>