Am Sonntag, 24. Januar 2021, 15:32:59 CET schrieb Ard Biesheuvel: Hi Ard, > On Sun, 24 Jan 2021 at 15:23, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Sun, 24 Jan 2021 at 15:10, Stephan Müller <smueller@xxxxxxxxxx> wrote: > > > 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
