Am Samstag, 12. Januar 2019, 10:55:35 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Jan 11, 2019 at 09:12:54PM -0800, Eric Biggers wrote: > > Hi Stephan, > > > > On Fri, Jan 11, 2019 at 08:10:39PM +0100, Stephan Müller wrote: > > > The RFC5869 compliant Key Derivation Function is implemented as a > > > random number generator considering that it behaves like a deterministic > > > RNG. > > > > Thanks for the proof of concept! I guess it ended up okay. But can you > > explain more the benefits of using the crypto_rng interface, as opposed > > to just some crypto_hkdf_*() helper functions that are exported for > > modules to use? > I agree. I see no benefit in adding this through the RNG API as > opposed to just providing it as a helper. If some form of hardware > acceleration were to eventuate in the future we could always revisit > this. The advantages for using the kernel crypto API to add KDFs as opposed to adding helper wrappers are the following in my view: - employment of the kernel crypto API testmgr - invocation of the testmgr is transparent and thus already provided without any additional code to link to it - FIPS 140-2 compliance: To mark a KDF as FIPS 140-2 approved cipher, it must be subject to a known-answer self test (implemented by the testmgr) as well as to an enforcement of the integrity check verification. In FIPS 140-2 mode, the kernel crypto API panic()s when a kernel crypto API module is loaded and its signature does not check out. As this is only relevant for crypto modules (and not arbitrary other kernel modules), this is implemented with the invocations the crypto_register_alg as well as crypto_register_template functions. Thus, when using a wrapper code to implement the KDF, they can per definition not be FIPS 140-2 approved. - The invoker of a KDF has one consistent API. This implies that the KDF selection now becomes more of a "configuration" choice. For example, when you look at the KDF use case for the keys subsystem (security/keys/dh.c), selecting the type of KDF would only necessitate a change of a string referencing the KDF. A lot of people somehow favor the extract-and-expand KDFs over the traditional KDFs. Now, that the RFC5869 HKDF is also approved as per SP800-56A rev3, I could see that folks may want to switch to HKDF for the key management. When we have a common API, this choice could even be left to the caller. 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. Ciao Stephan
