Am Dienstag, 16. August 2016, 17:13:47 CEST schrieb Herbert Xu:

Hi Herbert,

On Tue, Aug 16, 2016 at 11:11:47AM +0200, Stephan Mueller wrote:

quoted

Conceptually, a KDF is a random number generator by generating arbitrarily
sized strings from a fixed "seed". This lead me to add the RNG template
handling. Even the existing DRBG is more or less a "block chaining mode"
that is very similar to a KDF. Hence, the current plethora of 22
registered DRBGs could be elegantly eliminated if the DRBG is turned into
template using the proposed RNG framework.

The point is that there is no alternative implementation for kdf,
nor is there likely to be one.

I was thinking of the DRBG implementation: decouple it from the underlying 
ciphers. Though, I am not fully sure that will work as there are several 
specific settings that depend on the underlying ciphers (e.g. the state of a 
Hash DRBG with SHA-256 is 444 bits whereas a Hash DRBG with SHA-512 has 888 
bits).

quoted

If you think that a KDF should not be a generic mechanism, then the KDF
logic would need to move directly into the keys subsystem. But since TLS
is something folks speak about, a TLS KDF would need to be considered
eventually too which is yet again some form of RNG.

If a TLS KDF comes with a hardware implementation then we could
include it.  Otherwise the answer would be the same.

It is certainly not an issue to move the KDF logic into the keys subsystem. 
However, as it (may) resemble SP800-56A which is in line with FIPS 140-2, 
folks may ask for a FIPS stamp on it. If a FIPS stamp is asked for, the KDF 
itself must be subject to a self test (like what we have in testmgr.c). If we 
move the KDF to the keys subsystem, the self test would then need to be 
implemented there.

Ciao
Stephan