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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXE=46vk15Ovs8qS96JZRi2xDHHe=QqC=WKbZ-+gx4DL4Q@mail.gmail.com>
Date:   Sun, 24 Jan 2021 15:23:29 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Stephan Müller <smueller@...onox.de>
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

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.



> 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
>
>
>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ