From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A85D8C43387 for ; Sun, 13 Jan 2019 16:52:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 72E1C2089F for ; Sun, 13 Jan 2019 16:52:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="i4vN6VPI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726804AbfAMQw0 (ORCPT ); Sun, 13 Jan 2019 11:52:26 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:39502 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726596AbfAMQw0 (ORCPT ); Sun, 13 Jan 2019 11:52:26 -0500 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 06B128EE335; Sun, 13 Jan 2019 08:52:25 -0800 (PST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzwZyar6r92n; Sun, 13 Jan 2019 08:52:24 -0800 (PST) Received: from [153.66.254.242] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id CC5578EE31D; Sun, 13 Jan 2019 08:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1547398344; bh=97Lr8uEcWLYZCfQ65MhD1fQLYDaPb+MVY/qOho5BHrk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=i4vN6VPILuvlJrcNcY5cbZgiEzT4vGensEQ8uH+ALRauU3TvJTNmRl/WlRyLqNoRG rgkpR/W2mQWSIKc5keILKgkKPXCe3OWm6JRgFq2EKQeW434jbpBvF4qRV8Uwlhy+Kh VmwJbDdTZz4ZXzvriF/i6t8V5ipF4dQ9qvYM5NRg= Message-ID: <1547398342.4409.3.camel@HansenPartnership.com> Subject: Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function From: James Bottomley To: Stephan =?ISO-8859-1?Q?M=FCller?= , Herbert Xu Cc: Eric Biggers , 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 Date: Sun, 13 Jan 2019 08:52:22 -0800 In-Reply-To: <9795894.APlZEWIbOH@positron.chronox.de> References: <20190103143227.9138-1-jlee@suse.com> <20190112051252.GA639@sol.localdomain> <20190112095535.36rh3ptnrf7yxacv@gondor.apana.org.au> <9795894.APlZEWIbOH@positron.chronox.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2019-01-13 at 08:56 +0100, Stephan Müller wrote: > The question may arise why to plug the KDFs into RNGs. The answer is > quite simple: KDFs are a form of random number generator. In that > they take some input for initialization (aka seed, salt, key, > personalization string). Then they produce pseudo-random bit > sequences of arbitrary length. Possibly the generation operation can > be modified by providing some additional input to be used by the > generation process (aka label, context, info string, additional  > information string). Thus, the RNG interface is a natural fit for the > KDFs. Philosophically, that's quite wrong. KDFs are a class of pseudorandom functions (PRFs). PRFs are designed so that the output is indistinguishable from a random number generator to observers who don't know the input but is deterministically useful for participants who do. That means the're definitely not RNGs they're functions whose output is designed to look like the output of an RNG. I suppose the mathematical thing that distinguishes PRFs and RNGs is entropy: PRFs have zero entropy because given the same inputs you expect the same output. Now whether it makes sense to use the RNG API or not I'll leave that up to the crypto people. I would have expected any cryptographic RNG API to be mostly about entropy management (the Linux core internal one certainly is), but it appears that the one in crypto isn't. James