Am Sonntag, 24. Januar 2021, 15:32:59 CET schrieb Ard Biesheuvel:

Hi Ard,

On Sun, 24 Jan 2021 at 15:23, Ard Biesheuvel [off-list ref] wrote:

quoted

On Sun, 24 Jan 2021 at 15:10, Stephan Müller [off-list ref] wrote:

quoted

Hi,

The key derviation functions are considered to be a cryptographic
operation. As cryptographic operations are provided via the kernel
crypto API, this patch set consolidates the KDF implementations into the
crypto API.

The KDF implementations are provided as service functions. Yet, the
interface to the two provided KDFs are identical with the goal to allow
them to be transformed into a crypto API template eventually.

Why? There are typically two reasons to use the crypto API abstractions:
- the algorithm is not known at compile time, so we need the runtime
dispatch that the crypto API implements,
- the algorithm may be implemented by a h/w accelerator which is
discovered at runtime via the driver stack

In other cases, a library API is much more suitable, even in the case
where we may provide arch-specific accelerated implementations of such
an algorithm.

Hmm, apologies if I got the wrong end of the stick here - this prose
and the naming of some of the crypto_hkdf_xxx routines and function
pointers in the test code made me think that this is more than it
actually is.

What we are talking about are basically library wrappers around shash
instances to perform HKDF, right?

Sorry, our emails just crossed each other.

Yes, you are absolutely correct. The KDF implementations are wrappers around 
the SHASH API. Conceptually the provided API is what templates actually should 
do.

As mentioned in the other email, however, adding a template was and is not 
considered appropriate at the time. Yet, I would like to keep the path open to 
transform the KDF implementations into a template.

Ciao
Stephan