Update to JEP draft: Key Encapsulation Mechanism API

Sun Feb 5 06:24:33 UTC 2023

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230204/521e5629/attachment.htm>