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.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
