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 <[email protected]> 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/@[email protected]/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 <[email protected]> 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
>>
>
