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: > > 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). > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
