Update to JEP draft: Key Encapsulation Mechanism API

[Wei-Jun Wang]

What does "variable length shared-secret sizes" mean? In the current Java API design, this is not possible, as Ecapsulator.secretSize() returns a finite number. So it must be determined by algorithm name + KEMParamaterSpec + public key.

I don't think I added any flexibility here. If you mean the (algorithm, from, to) method, that's just for Java. In real KEM sense, there is only one define-size shared secret.

Thanks,
Max

> On Mar 7, 2023, at 12:43 PM, John Gray <John.Gray at entrust.com> wrote:
> 
> Thanks for this update.
> 
> It is possible future KEMs could have variable length shared-secret sizes, so having the ability to be flexible is needed.   Looks like you have covered all possible cases here.
> 
> Thanks for these additions!
> 
> Cheers,
> 
> John Gray
> Entrust
> 
> 
> -----Original Message-----
> From: security-dev <security-dev-retn at openjdk.org> On Behalf Of Wei-Jun Wang
> Sent: Friday, March 3, 2023 12:30 PM
> To: security-dev at openjdk.java.net
> Subject: [EXTERNAL] Re: Update to JEP draft: Key Encapsulation Mechanism API
> 
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
> 
> ______________________________________________________________________
> Hi All,
> 
> The JEP draft was just updated again.
> 
> 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.
> 
> Therefore we drop the class and directly put the fields in the argument list of the encapsulate method, i.e.
> 
>  encapsulate(int from, int to, String algorithm);
> 
> 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
> 
>  encapsulate();
> 
> that simply returns a SecretKey containing the full shared secret with algorithm name "Generic".
> 
> 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.
> 
>> 
>> Please take a look. The updated JEP is still at https://urldefense.com/v3/__https://openjdk.org/jeps/8301034__;!!FJ-Y8qCqXTj2!YplqJhcF4E24TPCPGDdbmukMBaEgm71og8rY95FsDzFlgXyu5XN73M7juERfHm5GY684RCo7E6MqmyS1MJWAsnJu1VhB$ .
>> 
> 
> Thanks,
> Max
> 
> 
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.