<html><body><div dir="ltr"><div style="">

    </div><div style=""><div>

        <div dir="ltr">Will „Generic“ work with ciphers which need „raw“, or is that intentionally not the case?</div><div dir="ltr">Btw I like the simplification.</div><div dir="ltr"><br></div><div dir="ltr">Gruss</div><div dir="ltr">Bernd </div><div id="ms-outlook-mobile-signature"><div style="direction:ltr">-- </div><div style="direction:ltr">http://bernd.eckenfels.net</div></div>

    </div>

<div> </div><hr style="display:inline-block;width:98%" tabindex="-1"><div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>Von:</b> security-dev <security-dev-retn@openjdk.org> im Auftrag von Wei-Jun Wang <weijun.wang@oracle.com><br><b>Gesendet:</b> Freitag, März 3, 2023 6:31 PM<br><b>An:</b> security-dev@openjdk.java.net <security-dev@openjdk.java.net><br><b>Betreff:</b> Re: Update to JEP draft: Key Encapsulation Mechanism API<div> </div></font></div>Hi All,

<br>

The JEP draft was just updated again.

<br>

The major change is that there is no more DerivedKeyParameterSpec class Maybe it's because of the name, but we found many people treating it as a place to configure the KDF used inside a KEM. Actually the only usage of it is to give caller a chance to wrap (possibly a portion of) the shared secret into a SecretKey.

<br>

Therefore we drop the class and directly put the fields in the argument list of the encapsulate method, i.e.

<br>

<br>  encapsulate(int from, int to, String algorithm);

<br>

<br>We also noticed that unlike traditional KEM algorithms (like RSA-KEM and ECIES) that allow a user to choose an arbitrary KDF output length so the generated shared secret can be directly used as a cipher key, modern KEM algorithms have a constant shared secret size, and the output of the KEM is usually passed into a KDF to generate more keys. Therefore we are now providing a shorter method

<br>

<br>  encapsulate();

<br>

that simply returns a SecretKey containing the full shared secret with algorithm name "Generic".

<br>

We hope this shorter method will be mostly used, and the longer one that takes from, to, and algorithm as arguments is only used for the traditional use case where the shared secret is directly used as a cipher key. This longer method might not always be supported by every implementation. For example, in PKCS #11 only a recognized algorithm can be mapped into a valid key type, and the key length must match the key type. In fact, if you want to derive an AES key but the size of the shared secret is bigger than your preferred key size, it's always the leading bytes of the shared secret that are removed. This means you can call encapsulate(secretSize() - 32, secretSize(), "AES") but calling encapsulate(0, 32, "AES") will throw an UnsupportedOperationException.

<br>

<br>> 

> Please take a look. The updated JEP is still at https://openjdk.org/jeps/8301034.

<br>> 

<br>

<br>Thanks,

<br>Max

<br>

<br>

<br></div></div></body></html>