linux-kernel - Re: [PATCH v2 0/7] Add KDF implementations to crypto API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3522419.MHq7AAxBmi@positron.chronox.de>
Date:   Sun, 24 Jan 2021 15:36:13 +0100
From:   Stephan Müller <smueller@...onox.de>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        Eric Biggers <ebiggers@...nel.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Mat Martineau <mathew.j.martineau@...ux.intel.com>,
        David Howells <dhowells@...hat.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-fscrypt@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        keyrings@...r.kernel.org, simo@...hat.com
Subject: Re: [PATCH v2 0/7] Add KDF implementations to crypto API

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@...nel.org> wrote:
> > On Sun, 24 Jan 2021 at 15:10, Stephan Müller <smueller@...onox.de> 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