All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: "Stephan Müller" <smueller@chronox.de>
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:23:29 +0100	[thread overview]
Message-ID: <CAMj1kXE=46vk15Ovs8qS96JZRi2xDHHe=QqC=WKbZ-+gx4DL4Q@mail.gmail.com> (raw)
In-Reply-To: <1772794.tdWV9SEqCh@positron.chronox.de>

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.



> The KDFs execute a power-on self test with test vectors from commonly
> known sources.
>
> Tbe SP800-108 KDF implementation is used to replace the implementation
> in the keys subsystem. The implementation was verified using the
> keyutils command line test code provided in
> tests/keyctl/dh_compute/valid. All tests show that the expected values
> are calculated with the new code.
>
> The HKDF addition is used to replace the implementation in the filesystem
> crypto extension. This code was tested by using an EXT4 encrypted file
> system that was created and contains files written to by the current
> implementation. Using the new implementation a successful read of the
> existing files was possible and new files / directories were created
> and read successfully. These newly added file system objects could be
> successfully read using the current code. Yet if there is a test suite
> to validate whether the invokcation of the HKDF calculates the same
> result as the existing implementation, I would be happy to validate
> the implementation accordingly.
>
> Changes v2:
>
> * change HKDF function names
> * change HKDF/SP800-108 KDF extract / seed function prototype
> * ensure clearing of memory of destination buffer in KDF implementation
>   if KDF operation fails
> * security DH: split the removal of dead code into separate patch
>
> Stephan Mueller (7):
>   crypto: Add key derivation self-test support code
>   crypto: add SP800-108 counter key derivation function
>   crypto: add RFC5869 HKDF
>   security: DH - remove dead code for zero padding
>   security: DH - use KDF implementation from crypto API
>   fs: use HKDF implementation from kernel crypto API
>   fs: HKDF - remove duplicate memory clearing
>
>  crypto/Kconfig                         |  14 ++
>  crypto/Makefile                        |   6 +
>  crypto/hkdf.c                          | 199 +++++++++++++++++++++++++
>  crypto/kdf_sp800108.c                  | 149 ++++++++++++++++++
>  fs/crypto/Kconfig                      |   2 +-
>  fs/crypto/hkdf.c                       | 103 +++----------
>  include/crypto/hkdf.h                  |  48 ++++++
>  include/crypto/internal/kdf_selftest.h |  71 +++++++++
>  include/crypto/kdf_sp800108.h          |  61 ++++++++
>  security/keys/Kconfig                  |   2 +-
>  security/keys/dh.c                     | 118 ++-------------
>  11 files changed, 586 insertions(+), 187 deletions(-)
>  create mode 100644 crypto/hkdf.c
>  create mode 100644 crypto/kdf_sp800108.c
>  create mode 100644 include/crypto/hkdf.h
>  create mode 100644 include/crypto/internal/kdf_selftest.h
>  create mode 100644 include/crypto/kdf_sp800108.h
>
> --
> 2.26.2
>
>
>
>

  parent reply	other threads:[~2021-01-24 14:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-24 14:01 [PATCH v2 0/7] Add KDF implementations to crypto API 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 ` Ard Biesheuvel [this message]
2021-01-24 14:32   ` [PATCH v2 0/7] Add KDF implementations to crypto API Ard Biesheuvel
2021-01-24 14:36     ` Stephan Müller
2021-01-24 14:34   ` Stephan Müller

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='CAMj1kXE=46vk15Ovs8qS96JZRi2xDHHe=QqC=WKbZ-+gx4DL4Q@mail.gmail.com' \
    --to=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 \
    --cc=smueller@chronox.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.