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.g...@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-r...@openjdk.org> On Behalf Of Wei-Jun Wang > Sent: Friday, March 3, 2023 12:30 PM > To: security-...@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.
