From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Mueller Subject: Re: [PATCH v2 3/4] crypto: kdf - SP800-108 Key Derivation Function Date: Thu, 02 Jun 2016 17:12:20 +0200 Message-ID: <20634336.6yV5j7Wfmz@tauon.atsec.com> References: <17649236.piPdUxUzaM@positron.chronox.de> <4593825.q48Y9K9RSZ@positron.chronox.de> <20160602085526.GA15919@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: linux-crypto@vger.kernel.org, David Howells , Mat Martineau , keyrings@vger.kernel.org To: Herbert Xu Return-path: Received: from mail.eperm.de ([89.247.134.16]:35716 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932099AbcFBPMY (ORCPT ); Thu, 2 Jun 2016 11:12:24 -0400 In-Reply-To: <20160602085526.GA15919@gondor.apana.org.au> Sender: linux-crypto-owner@vger.kernel.org List-ID: Am Donnerstag, 2. Juni 2016, 16:55:26 schrieb Herbert Xu: Hi Herbert, > > Why don't you put the result in a temporary buffer and then copy > it? These things are tiny, right? The KDFs are usually used for output sizes between one and 4 keys. So, commonly it is expected that not more than 200 or 300 bytes are generated by one call. But you cannot be sure how much data a user wants. The spec allows that the user generates up to 2^50 or so bytes. The implementation I offer is limited to unsigned int bytes. Note, if one would implement a key ladder, it can be expected that many keys are generated from one KDF seed. I tried to avoid memcpy for speed purposes. And all the user needs to do is to not invoke an in-place crypto operation. Maybe I should copy the input data into a private memory location so that the KDF can be used like any other cipher: the caller uses a reference to the instance to generate data where the caller does not need to ensure that some initial data must be left at some specific place. Ciao Stephan