From patchwork Fri Jan 11 19:08:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephan Mueller X-Patchwork-Id: 10760577 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3C9731869 for ; Fri, 11 Jan 2019 19:14:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2E8C629670 for ; Fri, 11 Jan 2019 19:14:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 226AC29778; Fri, 11 Jan 2019 19:14:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 97B2C2A009 for ; Fri, 11 Jan 2019 19:14:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390371AbfAKTN7 (ORCPT ); Fri, 11 Jan 2019 14:13:59 -0500 Received: from mo4-p03-ob.smtp.rzone.de ([81.169.146.174]:14454 "EHLO mo4-p03-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390318AbfAKTN6 (ORCPT ); Fri, 11 Jan 2019 14:13:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547234033; s=strato-dkim-0002; d=chronox.de; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=4AYi+MkUrKf+lfwSEQQdfE9a2fKEILbeYVFC8+EZ1GY=; b=n7SLib3xWjsNanqT0jce6PpC5tZ72dCLOYHMxw1PKMsbdrsVMvXp1j25tF+M9wXzuT kwB4XDVg5l7kvE/2sI+7pno9qsy7Bz9KgzV0h70jyNAX67Bw4NnQXIrMvGvEjbK0dj8s KIXqP/4Ezx6pjxc7wM4tZtmljy+90/zLYbXazCN/NkcJMjq7xCtfbVUvxD17Ee0uJYy1 dDJlX4aWKo/nE9Po8YcQSkbNTd/yt5nxBf0iozEFLMDg/RYooSGMvQB2ZZmcsNI3YSd3 1NbO6/0F4kNZT8xgg951EWCKimy3fXQAqJbqZhWXJWfipxtX7rHGYjiLQfPB4kgiSABh zd1g== X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzGHXPaLvSbdkg=" X-RZG-CLASS-ID: mo00 Received: from positron.chronox.de by smtp.strato.de (RZmta 44.9 DYNA|AUTH) with ESMTPSA id 309bcfv0BJDXflE (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 11 Jan 2019 20:13:33 +0100 (CET) From: Stephan =?iso-8859-1?q?M=FCller?= To: Eric Biggers , Herbert Xu Cc: James Bottomley , Andy Lutomirski , "Lee, Chun-Yi" , "Rafael J . Wysocki" , Pavel Machek , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Giovanni Gherdovich , Randy Dunlap , Jann Horn , Andy Lutomirski , linux-crypto@vger.kernel.org Subject: [PATCH 0/6] General Key Derivation Function Support Date: Fri, 11 Jan 2019 20:08:16 +0100 Message-ID: <9733066.Vrs4h5eWcW@positron.chronox.de> In-Reply-To: <20190109082103.GA8586@sol.localdomain> References: <20190103143227.9138-1-jlee@suse.com> <1894062.aDvIuj92vB@tauon.chronox.de> <20190109082103.GA8586@sol.localdomain> MIME-Version: 1.0 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Herbert, Eric, key derivation functions behave like a random number generator requiring a seed and can generate arbitrarily-sized bit sequences. As KDFs wrap ciphers, the first patch adds template support for the RNG part of the kernel crypto API. This allows the KDFs to be implemented as templates. The patches two through five add different KDFs. The immediate use in the kernel are: - SP800-108: security/keys/dh.c - HKDF: As Eric Biggers outlined, he wants to use HKDF for Ext4 FBE Other areas of the kernel implement KDFs which should be migrated to the common code base offered with this patch. The last patch adds the KDF invocation to tcrypt to allow an immediate test invocation of the KDFs which is at least needed for FIPS 140-2 compliance where the tcrypt module is insmod'ed during boot time to trigger the self tests. Eric, considering your request for supporting parallel use of HKDF, I instantiate the HMAC twice: once for the extract and once for the expand phase. The idea is that an extract operation does not collide too much with the expand operation (when using one instance of HMAC, the extract phase would invoke setkey with the salt and thus affect the expand phase). Though, the final extract phase setkey call with the PRK is non-atomic (at least in the software HMAC implementation). Thus, the caller would need to guarantee to invoke the extract phase while no expand phase operation is performed. So, maintaining two HMAC instances is not really required after all. What is your take on that? Stephan Mueller (6): crypto: add template handling for RNGs crypto: kdf - SP800-108 Key Derivation Function crypto: kdf - add known answer tests crypto: hkdf - RFC5869 Key Derivation Function crypto: hkdf - add known answer tests crypto: tcrypt - add KDF test invocation crypto/Kconfig | 13 + crypto/Makefile | 2 + crypto/hkdf.c | 290 ++++++++++++++++++++ crypto/kdf.c | 492 ++++++++++++++++++++++++++++++++++ crypto/rng.c | 44 +++ crypto/tcrypt.c | 8 + crypto/testmgr.c | 258 ++++++++++++++++++ crypto/testmgr.h | 225 ++++++++++++++++ include/crypto/internal/rng.h | 26 ++ 9 files changed, 1358 insertions(+) create mode 100644 crypto/hkdf.c create mode 100644 crypto/kdf.c