It seems that kmod's crypto/hashalgo (and thus tests) have seen limited attention since ~2013.
In that, we're still using the enum pkey_hash_algo from kernel v3.12. Upstream kernels have added an UAPI enum with ee08997fee16f10be23c9748d609dbdf3baab8e4 and the kernel tree was updated in 3fe78ca2fb1d61ea598e63fcbf38aec76b36b3a8.
Since then, kmod has gained SM3 support with some of caveats:
- our local copy has deviated from upstream, thus the non-openssl path was broken
- the openssl-side relied on compile-time guard
Follow-up commits upstream (v6.7) added SHA3 support, promted the openssl path of kmod to be updated \o/ Although the enum and non-openssl path fell deeper behind.
Rough ideas/tasks:
- update and ensure we don't deviate again
Namely, update the local enum copy and respective code-base. Add a test to check the size and contents of our vs upstream.
Reuse the style used for the sha1/256 ones.
- Potentially, revert 510c8b7 - aka go back to using NID to
enum pkey_hash_algo mapping...
Not sure to what extend the output of OBJ_obj2txt() is guaranteed to be stable. Also the openssl/crypto code-path is quite heavy, so we can drop the extra malloc and 2 function calls... Plus others like mbedtls, don't seems to have equivalent API.
It seems that kmod's crypto/hashalgo (and thus tests) have seen limited attention since ~2013.
In that, we're still using the
enum pkey_hash_algofrom kernel v3.12. Upstream kernels have added an UAPI enum with ee08997fee16f10be23c9748d609dbdf3baab8e4 and the kernel tree was updated in 3fe78ca2fb1d61ea598e63fcbf38aec76b36b3a8.Since then, kmod has gained SM3 support with some of caveats:
Follow-up commits upstream (v6.7) added SHA3 support, promted the openssl path of kmod to be updated \o/ Although the enum and non-openssl path fell deeper behind.
Rough ideas/tasks:
Namely, update the local enum copy and respective code-base. Add a test to check the size and contents of our vs upstream.
Reuse the style used for the sha1/256 ones.
enum pkey_hash_algomapping...Not sure to what extend the output of
OBJ_obj2txt()is guaranteed to be stable. Also the openssl/crypto code-path is quite heavy, so we can drop the extra malloc and 2 function calls... Plus others like mbedtls, don't seems to have equivalent API.