KDF JEP for the Java Platform

[Kevin Driver]

As a newly minted committer and Oracle employee tasked with the following, I thought I should send an introductory mail to the list and start a discussion on adding a standard API for key derivation functions (KDFs) to the Java Platform. You may have noticed the KEM [1] APIs and associated implementation coming in JDK 21. KDF [2] is another building block in support of HPKE [3] (which requires KEM and KDF as dependencies/primitives). HPKE will become important during the transition to post-quantum cryptography.

The concept of a KDF implementation within the security libraries is not entirely new (a JEP was put forth previously but withdrawn [4]); however it is time to formalize an API, add some additional implementations, and make some older implementations available for use in a more standard way.

We look forward to your feedback on the below proposal and would be interested in any thoughts on the design considerations listed at the end.

To wit, I’ll try to give a brief overview of the following:

- high level design
- current status
- design considerations

*High Level Design*

In general, this diagram encapsulates a lot of our intended trajectory (see attached diagram).

The new KDF APIs will serve as an umbrella over an RFC 5869 [5] implementation of HKDF, existing PBE implementations, and future implementations. However, our current plans are to allow algorithms, such as PBE, to continue to be accessible in the manner they are today (with possible deprecation at some point in the future).

In addition, JSSE has a “sibling” implementation of something very similar to RFC 5869 (but perhaps somewhat specialized for the JSSE use-cases), so it will likely be merged into the “proper”/main RFC 5869 implementation and called/utilized in a fashion similar to how JSSE does today. One goal is certainly to be minimally disruptive to JSSE implementation code where possible, so as to not incur a massive retesting/validation effort for TLS.

Also related to JSSE, one of the reasons for the Tls* classes (mentioned in the SunJCE provider) being located in restricted packages, I’m told, is because there was not yet a KDF API available. The classes described are in:

• sun.security.internal.interfaces
• sun.security.internal.spec

A side-goal/benefit of this work will be to relocate the above classes out of their restricted packages (ie - not in sun.security.internal any longer).

*Current Status*

Currently we (Oracle) have a set of KDF framework APIs as well as an implementation of RFC 5869 and a TLSPrfKDF implementation, which were developed previously but not yet made available. I have taken up this work, and I’m working through suggested modifications and/or improvements. There are, however, a few ongoing points of discussion, a couple of which I will be bringing forward today.

*Design Considerations*

• What, if any, JSSE implementations are there outside of Oracle which might be affected by the choice to relocate the Tls* classes from their SunJCE restricted packages? We are interested in speaking with those affected by this potential change.
• APIs in JCE have historically been “multi-phased” (ie - Cipher’s init, update, doFinal). However, it is also somewhat en vogue to lean toward immutability as much as possible. We’re weighing the relative merits of a “one and done” style API with lots of parameters vs a more “traditional” multi-phased approach.

[1] https://openjdk.org/jeps/452
[2] https://en.wikipedia.org/wiki/Key_derivation_function
[3] https://www.rfc-editor.org/rfc/rfc9180.html
[4] https://bugs.openjdk.org/browse/JDK-8189808
[5] https://www.rfc-editor.org/rfc/rfc5869.html

I will followup in a few weeks with more detail and will look forward to your feedback in the meantime. Thanks for your interest/participation!

Kevin Driver
Mobile: +1.512.431.5690
Java Security Libraries



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230720/cb1bbcef/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KDF Diagram.png
Type: image/png
Size: 121864 bytes
Desc: KDF Diagram.png
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230720/cb1bbcef/KDFDiagram.png>