> On Mar 3, 2023, at 12:37 PM, Bernd <e...@zusammenkunft.net> wrote: > > Will „Generic“ work with ciphers which need „raw“, or is that intentionally > not the case?
Not sure if I understand. "Raw" is the format type. "Generic" is similar to the GENERIC in pkcs11, and it is invented for KDF and maybe it can also be used with Hmac. Hmac also happens to be the only consumer of a SecretKey that does not care about the algorithm. Finally, it's up to the implementation to decide whether they accept a key of an unexpected algorithm name. IIRC, in the builtin provider of OpenJDK, all ciphers requires the algorithm name to be thing they recognize. Thanks, Max > Btw I like the simplification. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > Von: security-dev <security-dev-r...@openjdk.org> im Auftrag von Wei-Jun > Wang <weijun.w...@oracle.com> > Gesendet: Freitag, März 3, 2023 6:31 PM > An: security-...@openjdk.java.net <security-...@openjdk.java.net> > Betreff: Re: Update to JEP draft: Key Encapsulation Mechanism API > 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://openjdk.org/jeps/8301034. > > > > Thanks, > Max > >
