Update to JEP draft: Key Encapsulation Mechanism API

Sun Feb 5 14:31:04 UTC 2023

var cek = KeyGenerator.getInstance("ZES").generateKey();

var ikm = KEM.getInstance("DHKEM”, pkR, new DerivedKeyParameterSpec("HKDF")).encapsulate().key();
var kek = KDF.getInstance("HKDF", ikm, new DerivedKeyParameterSpec("YESWrap", 32)).extract();
var ek = Cipher.getInstance("YESWrap").init(WRAP, k2).wrap(cek);

Hopefully we can find a YESWrap cipher than accepts kek and is able to wrap cek.

I'll try to see if this is describable when I'm fully back to work state on Monday.

Thanks and Happy Rice Ball Day!

--Max

> On Feb 5, 2023, at 1:24 AM, Xuelei Fan <xuelei.f at gmail.com> wrote:
> 
> 
> On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang <weijun.wang at oracle.com> wrote:
> Hi Xuelei,
> 
> This is a very interesting case since both crypto primitives (KEM and Cipher) require delayed provider selection.
> 
> I would say line 4 should not throw an exception. A KEM should not reject any algorithm name, because it might be any string. It's very likely that the shared secret is then be passed into a KDF. I don't think there is a convention on what the algorithm name should be used for the input of a KDF. Should any KEM reject the "TlsPreSharedSecret" algorithm name? Maybe not.
> 
> 
> I'm not sure unless there is a specification that says so.  If you are sure of it, please make it clear in the specification so that the implementation could be guided accordingly.
> 
>   In your example, it's very unfortunate that the real ZES implementation is not able to use the unextractable key generated by a KEM in another provider. I assume some considerations on a proper provider order might be necessary, or the user might need to think about picking up a provider explicitly.
>  Unfortunately, an application may not want to pick up a provider explicitly or specify the order, especially if code update is required or the application needs to work generally.
>  You can imagine this becoming more of a problem in the KEM -> KDF -> Key Wrapping Cipher -> Data Encryption Cipher case, which is a very typical combination in today's secure data exchange.
> 
> 
> Anyway, the issue is not new.  There were similar cases when RSASSA algorithms were introduced.  There is not much one can do for the existing RSA classes.  But for new classes, the story could be new.  That's why I asked the question,  "what’s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec?" If the parameters can be treated similar to algorithm name and KEMParameterSpec that specified at getInstance method, as if the classes has been designed as more immutable, the APIs may look different.
> 
> -  var kemS = KEM.getInstance("DHKEM”);
> + var kemS = KEM.getInstance("DHKEM”, pkR, new DerivedKeyParameterSpec("AES", 32));
> 
> Best,
> Xuelei
> 
>   Thanks,
> Max
> 
> 
> > On Feb 4, 2023, at 10:44 AM, Xuelei Fan <xuelei.f at gmail.com> wrote:
> > 
> > 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://urldefense.com/v3/__https://mastodon.social/@eckes@zusammenkunft.net/109752008992193461__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXz4sePXo4$ 
> >> [2] https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html*name-transmitting-public-keys-an__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzNgH0GW8$  <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzwgQIN5I$ >
> >> [3] https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5990*appendix-A.2__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzF2ogx9M$ 
> >> [4] https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzP6fP4sc$ 
> >> 
> >> 
> >>> 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
> 
> 