On Wed, Oct 16, 2024 at 08:40:54AM +0200, Hannes Reinecke wrote: > On 10/15/24 17:41, Eric Biggers wrote: > > On Tue, Oct 15, 2024 at 05:05:40PM +0200, Hannes Reinecke wrote: > > > On 10/14/24 21:38, Eric Biggers wrote: > > > > On Fri, Oct 11, 2024 at 05:54:22PM +0200, Hannes Reinecke wrote: > > > > > Separate out the HKDF functions into a separate module to > > > > > to make them available to other callers. > > > > > And add a testsuite to the module with test vectors > > > > > from RFC 5869 to ensure the integrity of the algorithm. > > > > > > > > integrity => correctness > > > > > > > Okay. > > > > > > > > +config CRYPTO_HKDF > > > > > + tristate > > > > > + select CRYPTO_SHA1 if !CONFIG_CRYPTO_MANAGER_DISABLE_TESTS > > > > > + select CRYPTO_SHA256 if !CONFIG_CRYPTO_MANAGER_DISABLE_TESTS > > > > > + select CRYPTO_HASH2 > > > > > > > > Any thoughts on including SHA512 tests instead of SHA1, given that SHA1 is > > > > obsolete and should not be used? > > > > > > > Hmm. The original implementation did use SHA1, so I used that. > > > But sure I can look into changing that. > > > > If you're talking about fs/crypto/hkdf.c which is where you're borrowing the > > code from, that uses SHA512. > > > Actually, I was talking about the test vectors themselves. RFC 5869 only > gives test vectors for SHA1 and SHA256, so that's what I've used. > I've found additional test vectors for the other functions at > https://github.com/brycx/Test-Vector-Generation/blob/master/HKDF/hkdf-hmac-sha2-test-vectors.md > so I'll be using them for adding tests for SHA384 and SHA512 (TLS on > NVMe-over-TCP is using SHA384, too) and delete the SHA1 ones. Right, it's an old spec, so that's why it has SHA1. Using SHA512 test vectors from elsewhere, or generating your own test vectors using a known-good implementation, would be fine though. - Eric
