Keyrings Archive on lore.kernel.org
 help / color / Atom feed
From: "Stephan Müller" <smueller@chronox.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@kernel.org>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Mat Martineau <mathew.j.martineau@linux.intel.com>,
	David Howells <dhowells@redhat.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	keyrings@vger.kernel.org, simo@redhat.com
Subject: Re: [PATCH v2 0/7] Add KDF implementations to crypto API
Date: Sun, 24 Jan 2021 15:34:02 +0100
Message-ID: <4083606.ejJDZkT8p0@positron.chronox.de> (raw)
In-Reply-To: <CAMj1kXE=46vk15Ovs8qS96JZRi2xDHHe=QqC=WKbZ-+gx4DL4Q@mail.gmail.com>

Am Sonntag, 24. Januar 2021, 15:23:29 CET schrieb Ard Biesheuvel:

Hi Ard,

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

In case your "why" refers to why I stated that the KDF implementations are 
similar to eventually consolidate them into a template eventually:

A KDF is conceptually a logic on top of a (hash) algorithm like a block 
chaining mode on top of a block cipher or a deterministic RNG on top of an 
underlying cipher.

So, conceptually with the kernel crypto API, we would have a KDF template that 
can be used like hkdf(sha256) or hkdf(sha256-avx2).

The behavior of a KDF is identical to a deterministic RNG. Thus, a long time 
ago, I had a patch developed that adds a very small addition to the existing 
RNG API to allow the KDFs to be used. See [1]. Yet, that was not desired at 
the time due to different reasons.

Yet, the crypto API as it stands today knows of templates and basic 
algorithms. Having a separate library API providing a crypto algorithm is new 
to the crypto API. You see that with the test manager which works well with 
the templates / algorithms but does not provide any helpers for some "library 
APIs".



In case your "why" refers to whether I am not using a template to begin with:

Some time back I provided the patch using a template (see [1] for example). At 
that time, Herbert wanted to have a service API instead.

[1] http://www.chronox.de/kdf.html

Ciao
Stephan



      parent reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-24 14:01 Stephan Müller
2021-01-24 14:01 ` [PATCH v2 1/7] crypto: Add key derivation self-test support code Stephan Müller
2021-01-24 14:02 ` [PATCH v2 2/7] crypto: add SP800-108 counter key derivation function Stephan Müller
2021-01-24 14:03 ` [PATCH v2 3/7] crypto: add RFC5869 HKDF Stephan Müller
2021-01-28 20:08   ` Eric Biggers
2021-01-24 14:03 ` [PATCH v2 4/7] security: DH - remove dead code for zero padding Stephan Müller
2021-01-24 14:04 ` [PATCH v2 5/7] security: DH - use KDF implementation from crypto API Stephan Müller
2021-01-24 14:04 ` [PATCH v2 6/7] fs: use HKDF implementation from kernel " Stephan Müller
2021-01-28 20:16   ` Eric Biggers
2021-01-28 20:18   ` Eric Biggers
2021-01-24 14:04 ` [PATCH v2 7/7] fs: HKDF - remove duplicate memory clearing Stephan Müller
2021-01-28 20:21   ` Eric Biggers
2021-01-24 14:23 ` [PATCH v2 0/7] Add KDF implementations to crypto API Ard Biesheuvel
2021-01-24 14:32   ` Ard Biesheuvel
2021-01-24 14:36     ` Stephan Müller
2021-01-24 14:34   ` Stephan Müller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4083606.ejJDZkT8p0@positron.chronox.de \
    --to=smueller@chronox.de \
    --cc=ardb@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathew.j.martineau@linux.intel.com \
    --cc=simo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Keyrings Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/keyrings/0 keyrings/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 keyrings keyrings/ https://lore.kernel.org/keyrings \
		keyrings@vger.kernel.org
	public-inbox-index keyrings

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.keyrings


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git