<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 4, 2023 at 2:33 PM Wei-Jun Wang <<a href="mailto:weijun.wang@oracle.com">weijun.wang@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Xuelei,<br>
<br>
This is a very interesting case since both crypto primitives (KEM and Cipher) require delayed provider selection.<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.</blockquote><div> </div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>- var kemS = KEM.getInstance("DHKEMâ€);<br></div><div>+ var kemS = KEM.getInstance("DHKEMâ€, pkR, new DerivedKeyParameterSpec("AES", 32));</div><div><br></div><div>Best,</div><div>Xuelei</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
Max<br>
<br>
<br>
> On Feb 4, 2023, at 10:44 AM, Xuelei Fan <<a href="mailto:xuelei.f@gmail.com" target="_blank">xuelei.f@gmail.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> Thank you for the update. <br>
> <br>
> What’s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I’m not very sure of it. <br>
> <br>
> For example, at 2013, the following cord should work without any issues:<br>
> 1. var kemS = KEM.getInstance("DHKEMâ€);<br>
> 2. var pkR = retrieveKey();<br>
> 3. var e = kemS.newEncapsulater(pkR);<br>
> 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));<br>
> 5. var secS = enc.key();<br>
> 6. sendBytes(enc.encapsulation());<br>
> <br>
> <br>
> At 2023, a new DerivedKeyParameterSpec algorithm or spec could be defined. For example, the new algorithm is “ZESâ€. An application may use “ZES" as:<br>
> <br>
> 1. var kemS = KEM.getInstance("DHKEMâ€);<br>
> 2. var pkR = retrieveKey();<br>
> 3. var e = kemS.newEncapsulater(pkR);<br>
> - 4. var enc = e.encapsulate(new DerivedKeyParameterSpec("AES", 32));<br>
> + 4. var enc = e.encapsulate(new DerivedKeyParameterSpec(“ZES", 32));<br>
> 5. var secS = enc.key();<br>
> 6. sendBytes(enc.encapsulation());<br>
> <br>
> <br>
> 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.<br>
> <br>
> Thanks,<br>
> Xuelei<br>
> <br>
>> On Feb 3, 2023, at 2:53 PM, Wei-Jun Wang <<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a>> wrote:<br>
>> <br>
>> Hi All,<br>
>> <br>
>> 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?<br>
>> <br>
>> David Hook mentioned that RSA-KEM has a similar problem.<br>
>> <br>
>> 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.<br>
>> <br>
>> 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.<br>
>> <br>
>> Please take a look. The updated JEP is still at <a href="https://openjdk.org/jeps/8301034" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8301034</a>.<br>
>> <br>
>> Thanks,<br>
>> Max<br>
>> <br>
>> [1] <a href="https://urldefense.com/v3/__https://mastodon.social/@eckes@zusammenkunft.net/109752008992193461__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXz4sePXo4$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://mastodon.social/@eckes@zusammenkunft.net/109752008992193461__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXz4sePXo4$</a> <br>
>> [2] <a href="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$" rel="noreferrer" target="_blank">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$</a>Â <<a href="https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzwgQIN5I$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzwgQIN5I$</a> ><br>
>> [3] <a href="https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5990*appendix-A.2__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzF2ogx9M$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc5990*appendix-A.2__;Iw!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzF2ogx9M$</a> <br>
>> [4] <a href="https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzP6fP4sc$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!ACWV5N9M2RV99hQ!KAtLXILhpqph6FkII6RZKd7jmn8qR-JGxoND05heumt0tLfOKisPsusM_LadO8sacX4ZK7Q5jyXzP6fP4sc$</a> <br>
>> <br>
>> <br>
>>> On Jan 25, 2023, at 2:24 PM, Wei-Jun Wang <<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a>> wrote:<br>
>>> <br>
>>> Hi All,<br>
>>> <br>
>>> 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.<br>
>>> <br>
>>> You can read the draft JEP at <a href="https://openjdk.org/jeps/8301034" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8301034</a>.<br>
>>> <br>
>>> Feel free to add any comment here.<br>
>>> <br>
>>> Thanks,<br>
>>> Max<br>
<br>
<br>
</blockquote></div></div>