From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Mueller Date: Wed, 09 Jan 2019 18:18:13 +0000 Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Message-Id: <2049180.FbvvROCS3Z@tauon.chronox.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: <20190103143227.9138-1-jlee@suse.com> <2344329.gmPllosFfp@tauon.chronox.de> <20190109173454.GB249140@gmail.com> In-Reply-To: <20190109173454.GB249140@gmail.com> To: Eric Biggers Cc: James Bottomley , Andy Lutomirski , Herbert Xu , "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 Am Mittwoch, 9. Januar 2019, 18:34:55 CET schrieb Eric Biggers: Hi Eric, > That would not meet my performance requirements as I want to precompute > HKDF-Extract, and then do HKDF-Expand many times. Also the HKDF-Expand part > should be thread-safe and not require allocating memory, especially not a > whole crypto_shash tfm every time. > > So presumably with crypto_rng, crypto_rng_reset() would need to take the > input keyring material and salt and do HKDF-Extract (like my > fscrypt_init_hkdf()), and crypto_rng_generate() would need to take the > application-specific info string and do HKDF-Expand (like my > fscrypt_hkdf_expand()). Great, that was the idea I had in mind as well. Maybe the example was not right to convey that. Let me work on that. > > It is ugly though. Please also consider just having simple crypto_hkdf_*() > helper functions which wrap a HMAC tfm along the lines of my patch, rather > than shoehorning it into the crypto_rng API. > > - Eric Ciao Stephan